On Fri, Apr 27, 2018 at 4:17 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > It would be helpful to know where opponents stand on negotiating > continued use of the extension in general and in the future. We > are confused by their statements so far, and wonder if they are > not just generally in opposition to any negotiation of continued > support for the extension (in all applications), and whether that > might be driving their opposition to the 16 bits, whether consciously > or not. > Hi Viktor, I am in support of doing the pinning in a new extension, and will even help you write the draft if you like. I'm pretty sure we could have easily done this in the time that has been taken up on list endlessly and repetitively discussing this. Clearly I can speak only for myself, but I strongly suspect others in the WG will also support this (as long as it's in a separate extension), so if you pursue this approach, I think you'll succeed in adding this functionality, and will not be actively blocked by others. As far as I can assess, the reason you are getting resistance for adding a pinning field in this spec is two fold: First, there is no agreement that your reason for doing pinning, i.e. that DANE needs downgrade resistance against PKIX attacks is even valid. This can be clearly seen from various comments on list and at IETF/London, such as the point made many times that the original purpose of this draft was to add DANE as an additional possible authentication mechanism in TLS, not to position it as a mechanism that if available unconditionally trumps PKIX authentication. If you look back at my back-and-forth answering IESG review comments, you will observe that I had to add text to the draft that says TLS clients can fail back to normal PKIX authentication if DANE fails for any reason (i.e. a protocol behavior that is the opposite of downgrade resistance). There are other comments like (paraphrasing) "What's the downgrade problem? The only security downgrade issue I see is DNSSEC's use of legacy crypto"? Clearly, for most DANE proponents, an obvious goal for the protocol would be to protect against PKIX attacks. In an ideal world, I share that view also. But I also recognize the other views I just described, and am willing to make compromises to get a foot in the door for DANE first. There will always be opportunities to improve the protocol later. In fact, the legacy crypto issue will always be a huge impediment for any DANE proponent in arguing against the Internet PKI. An argument I've heard many times: Since most of the Internet PKI has moved to 2048-bit RSA or better, why would I degrade the security of my system by moving to DANE, which in most cases is protected by 1024-bit RSA ZSK's in the weakest part of the chain (some chains are even weaker)? And if so, why should PKIX not need downgrade resistance against DANE, rather than vice versa? For DANE proponents to make a stronger case, they need to urgently solve this problem. I'm not sure how to do that quickly - it probably involves getting ICANN to impose rules on TLDs prohibiting weak keys (which would likely take years). The second reason is that pinning really is a controversial feature. And for this reason, putting it in the core spec will be difficult. I won't repeat all the arguments and concerns expressed already, many of which I share by the way. So moving this feature into a new optional extension (both the pinning field and a description of the associated behavior) appears to me to be the past of least resistance. By continuing to argue your position, the most you can hope to achieve is deadlock. Shumon. (Addendum: I did want to thank you for pushing on the issue of explicitly allowing authenticated denial of existence chains in the current draft. In environments where all TLS servers support this extension, this allows the protocol to be bulletproof in a way that satisfies even the security purist, so I'm glad it's in the core spec.). -- Shumon Huque
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls