On Wed, Jun 20, 2018 at 2:12 PM, Salz, Rich < [email protected]> wrote: > > > The idea is to see implementations, confirm proper functioning and > then (maybe with some minor changes that we learned from running the > experiment) publish this as Proposed Standard. > > Do you have any indication that anyone else is looking at deploying this? > I mean "experiment" is a pretty weak enticement, especially compared to a > proposed Internet standard. I believe there will be no experiments > deployed. From everything I've seen, the community is focused only on 6962. >
I'm not sure what you mean by "enticement". The document status is by no means an enticement to implementation. I think your belief that there will not be experiments is not well-founded. Google is strongly interested in 6962-bis. While 6962 is being required for new certificates, it is merely a stepping stone towards the overall goal of CT as a holistic ecosystem. 6962-bis provides a number of compelling advantages over 6962, both in terms of protocol and in terms of the policy options it affords. For example, certain policy options are simply not available under 6962 while obtaining the necessary privacy and performance goals of all participants in the ecosystem. Google is interested in supporting 6962-bis in its open-source log software. Chrome is interested in supporting 6962-bis in its client software. I can't speak for the log software timeline, but Chrome sees this as something to be looking at for 2019, rather than 2018, due to significant changes already underway in the Web PKI - such as the rollout of 6962 and the deprecation of trust in large CAs. I can't speak for other user agents, but in our discussions with them, it appears there's consensus that 6962-bis allows deeper explorations of policy challenges that remain unaddressed by 6962 (at least, not without sacrificing some essential property that is non-negotiable). To successfully experiment, it will need log operators and CAs willing and able to do experiments, side-by-side with 6962. That is, dedicated -bis logs, and CAs logging to both 6962 and 6962-bis logs and presenting SCTs from both. 6962 and 6962-bis will need to exist side-by-side for some time. It is not expected that CAs will be required to adopt 6962-bis until such experiments have been done, and so the notion of a flag day transition is simply non-viable. It's helpful to think of this as something akin to the -draft experiments done by TLS1.3, working from an idealized protocol on paper into one that can be successfully and interoperably be deployed at Web scale. Just as with TLS1.3 discussions, there will no doubt be practical tradeoffs that need to be made that sully the platonic ideal of the protocol, but ensure the ability to successfully deploy. Unlike TLS1.3, however, the ecosystem interoperability tests require much greater timeframes, and so the notion of 1-2 year long inter-draft stages is also not viable. Chrome's focus on communicating this view and understanding has been with other log operators and user agents, as those most affected by both the policy implications and the technical roadmaps. I can understand we've been relatively quiet within this WG, both in part because the IETF process model does not lend itself well to how browsers are developed and iterate, and due to other significant changes in the Web PKI going on during the same period. In this regard, the experimental status is both an accurate and near-ideal representation of where 6962-bis is and the value it can bring, while also highlighting that the validation of the ideas and improvements in 6962-bis will take time. As the recent issues with the Threat Model document highlight, or the recent issues discussing Cloudflare's reading of 6962 vs the intent of Chrome, even the present document can benefit from improvements and clarifications that only reveal themselves once there are real world implementations being worked on.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
