On Sat, 28 Apr 2018, Shumon Huque wrote: [ not going to repeat my technical arguments here, just going to comment on process ]
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 is incorrect. From the replies to the consensus call on the list, it actually weights in favour of _some_ kind of downgrade resistance. In fact, it worries me that the consensus call outcome seems to come from non-public voices and not from a tally of those participants on the TLS list.
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..
This is actually upsetting. I can assure you that since the late 90's, people were working on DNSSEC as an alternative for the webpki. I wrote RFC 7901 as a building block for doing so, and that RFC is now the basis of the format of the data in this document. It is an explicit goal of _some_ people at IETF and has been for decades. What the motivation is of the individual document editor is not relevant. Once the document was adopted by the WG it became a document that needs to represent WG consensus, not original author intent. I will agree to the point that people in the webpki sphere dislike DNSSEC and don't want to see it competing against webpki. But writing specifications to limit alternatives is not what the IETF is about. The two byte is too much argument is simply a strawman argument. The "additive use case" is a completely made up concept. No one in their right minds will want a security model of "DANE or WebPKI, whichever is weaker".
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).
No one is objecting to that text.
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"?
Everyone makes mistakes, even people in the IESG. Viktor, Nico and I have clearly explained the downgrade attack. If your argument is that the IESG said otherwise and we should believe them, then the IESG is wearing no clothes, unless the specific IESG individual will show us the technical argument of why there allegedly is no downgrade attack.
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.
This is again not the proper argument to have. We make arguments based on technical merit and not based on "other [political] views". The technical points against a two byte zero value are non-existent.
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,
At this rate, this RFC won't be ready before .com is using 2048bit ZSK's. The argument is pretty weak and ephemeral and should not be an argument when writing RFCs.
why should PKIX not need downgrade resistance against DANE
It already has that by simply not using DANE, which is what all current browsers already (sadly) do. The refusal of the two byte value however, does not reciprocate that freedom to those users who voluntarilly want to move away from webpki towards dane-only.
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).
Strawman. From what I know, Versign is already investigating the ZSK key length for its zones. Regardless of if that would take years or not, publishing new RFCs that for no reason prohibit moving towards this added security is not what the IETF should be doing.
The second reason is that pinning really is a controversial feature. And for this reason, putting it in the core spec will be difficult.
That is not a technical argument. And Viktor's proposal of just adding the two bytes set to a mandatory 0 in this specification moves the discussion of how/when to pin this extension to that other new document that will see new (technical) discussion. So your argument here is only in favour of those two bytes to ensure proper extension pinning discussion happens in the new to be written specification.
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.
The path of least resistance is not the same as rough consensus.
By continuing to argue your position, the most you can hope to achieve is deadlock.
The exact same can be said of you, when you will face the inevitable Appeal Process. Paul _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
