On Wed, Apr 4, 2018 at 1:50 PM, Joseph Salowey <j...@salowey.net> wrote:
> Hi Folks, > > Some objections were raised late during the review of > the draft-ietf-tls-dnssec-chain-extension. The question before the > working group is either to publish the document as is or to bring the > document back into the working group to address the following issues: > > - Recommendation of adding denial of existence proofs in the chain > provided by the extension > - Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > > This is a consensus call on how to progress this document. Please answer > the following questions: > > 1) Do you support publication of the document as is, leaving these two > issues to potentially be addressed in follow-up work? > Yes. I support the publication of the document as is. and would like to explain my position a bit. I'm very sympathetic to Viktor's desire to enhance this protocol to provide downgrade resistance against PKIX attacks, and I generally would share that desire too. But I would also like to publish a document that has the solid consensus of the community that is one of key potential target consumers of this draft (web browsers and servers). So I'm giving more weight to their views and preferences. To date, the only people from that community that have spoken up have expressed strong opposition to Viktor's proposed enhancement. I also feel that the amount of time it has taken to finish up this draft has significantly hurt its deployment chances. In the early days of this draft there was (in my view) a window of opportunity where some browsers had actual interest in implementing this spec. But in the intervening time, there have been enough bandaids (CT and strengthed CAB forum requirements) applied to the WebPKI that to many people in the web community, the risk of bad actors has been sufficiently mitigated. But to the extent that there are still some folks interested in this proposal, I see no benefit in proposing an additional feature that they've stated doesn't work for them, or that they will not use. Another important facet of this debate that so far has not surfaced on recent mailing list discussions is an assessment of the relative benefits of webpki versus dane, and the recognition that there are strongly divergent views on this topic. In the early days of this draft, a number of web folks made it quite clear to me that this protocol can't be used to compel the use of DANE, and that the browser gets to decide what to use (and so dane-to-pkix downgrade attacks were not a concern for them). The large majority of DNSSEC proponents I know (and I'll state upfront that I'm one of them) clearly feel that DANE is superior to webpki, and that it's logical that DANE should be used to address webpki security issues. But this view is not shared by many others, most particularly in the web community. I've been involved in many lengthy debates on this topic, and the arguments against DANE usually boil down to: (1) widespread use 1024-bit RSA as the weak link in the majority of DNSSEC chains, (2) mistrust of registrars and their potential security failings, (3) mistrust of registries and/or other ancestor zones that could mount targeted attacks that could only be detected by a DNSSEC key transparency system, ala CT. These are legitimate arguments, and until we have better answers to them, I'm not inclined to aggressively push DANE, and position it as unconditionally superior, on communities that have expressed these concerns. Viktor has asserted that no-one will be motivated to deploy DANE without protection against PKIX downgrade, because there is no compelling enough additional gain of security. He may be right or wrong, but I've already heard several web folks disagree with him. And furthermore, they've expressed what I think are legitimate concerns about the fragility of the pinning proposal. Yes, I agree that it's not as bad as HPKP, but I also agree that there are more risks and failure possibilities than HSTS. As for other applications, we've already heard from a number of folks in the DNS over TLS camp that the draft works for them in the current form. Most DNS over TLS clients are expected to have explicit configuration of their resolver addresses and DANE capabilities. Some possible ways forward I see for folks wanting to develop a version of this spec with PKIX downgrade resistant capabilities (I've already stated earlier, that I would be happy to participate in such efforts): * Develop a new spec, with a new codepoint, and let the specs compete for adoption. * Develop a -bis document - if we manage to get WG consensus on the approach at a later date. * Do something outside the protocol, and specific to applications that want to include mechanisms to mandate DANE usage (like a HTTP header). -- Shumon Huque
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
