On Wednesday 08 June 2016 19:29:07 Peter Gutmann wrote: > Russ Housley <hous...@vigilsec.com> writes: > >I do not think the TLS WG should take on any document that makes > >changes to the TLS 1.2 protocol. > > So how is that different from any number of other TLS standards-track > RFCs, say, RFC 7627 (one of the ones referenced in the draft), which > was adopted as a WG document and standards-track RFC? The tiny > changes in this draft (adding one field to the ServerDHParams, using > the full MAC for finished, and hashing the full hello instead of just > one field in it) are pretty trivial in comparison to the > aforementioned RFC 7627, or any number of other ones.
<bikeshed> to be pedantic, the RFC describes itself "a profile" while in reality it modifies the protocol in a way that will make it incompatible with "vanilla" TLS 1.2 implementations (yes, I know it's negotiated using extension so it doesn't make it actually incompatible, just noting that the behavior with and without extension is significantly changed - it's not a strict subset of TLSv1.2) </bikeshed> -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
