On Wed, 4 Jul 2018, Eric Rescorla wrote:
In any case, as Martin Thomson says, we have a perfectly good extension mechanism which can be used to add pinning later without creating any placeholder here.
The IETF should not publish security protocols that are trivially downgraded. The work _should_ really be completed within this document to address all downgrade attacks. As a _compromise_ there have been suggestions done to let this document be published while commiting to a method for downgrade protection. That was not an invitation to punt it to infinity or an invitation to have a bis replace this entire document just to be ignored because some people only care about the DOH case. Besides, we would end up with identical specs apart from two bytes and the same discussion about these two bytes would happen about whether the new document Obsoletes: this one. It won't resolve the issue at all and meanwhile some people have implemented and deployed a protocol that can be trivially downgraded, or bothered to just not implement because it offers no real security benefit. If you don't like TLS extension pinning, come up with another mechanism that resolves the downgrade attack. But note that none of the comments against using two bytes for hour scale extension pinning withstood scrutiny and half of them were appeals to authority or based on people's gut feelings. So far, I've only heard incorrect comparisons with other pinning mechanism problems that ignore the fact that the source of this extension material is in DNSSEC and that the extension data is a "live snapshot" of active DNSSEC data and thus never stale/old/bad/brokeb.
That would first require there being consensus to do pinning.
Again, why do you think it would be even valid to have consensus to deploy a trivially downgradable security mechanism? I would certainly expect the IESG to send this back to the drawing board, even if they missed it on their first evaluation round. Paul _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
