On Thu, Oct 8, 2015 at 11:22 PM, Martin Rex <m...@sap.com> wrote: > Eric Rescorla wrote: > > Short, Todd <tsh...@akamai.com> wrote: > >> > >> However, for those ClientHello?s that support older versions, the > >> compression_method field may contain other values. This means that if a > >> TLSv1.3 client happened to support compression for TLSv1.2, it would be > >> unable to negotiate that via a single ClientHello. There?s no way to > >> attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in a > >> single ClientHello. > > Yup, that is the problem with the current text.
Thanks for clarifying this. > > > > > >> In effect, the document is stating that a TLSv1.3 client MUST NOT > support > >> compression, regardless of the protocol version that may be negotiated. > > > > Yes, this is what I believe it says and what I believe the WG had > consensus > > on, the reasoning being that we really wished to just remove the feature > > entirely. If the chairs declare consensus on something else, I will of > > course edit it to say something else. > > The current text is trying to force a specific policy in a fashion > that is in the worst conceivable violation of rfc2119 section 6 that > is possible. > > A ClientHello with > > ClientHello.client_version = (3,3) > ClientHello.compression_methods = (1,0) > > will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers. > > > ClientHello.client_version = (3,4) > ClientHello.compression_methods = (1,0) > > will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers, > but TLSv1.3 servers that follow the stupid idea will choke and > abort with an "illegal_parameter" alert. > > Essentially, the current wording is calling for a newly creating what > must be called a "compression method intolerance" -- but essentially > it is indistinguishable from a "TLS version intolerance" Hmm... I'm not sure I follow this argument. We have a bunch of rules for how TLS 1.3 clients MUST behave and TLS 1.3 servers will choke if they don't. This doesn't create any present interop problem and only creates a problem if in future we wish to reintroduce compression. Is that your concern? > For a number of years, it seemed to have been consensus in the IETF TLS WG > that TLS version intolerance is an implemenattion defect and a real > problem. > It would be sad if the current TLS WG would confirm that recklessly adding > handshake failure causing new intolerances into TLSv1.3 is the new > engeneering approach. As I said, I edited the document in conformance with what I believed the chair declaration of WG consensus was. If the WG consensus is to remove this requirement, then I will of course do so. So, rather than going back and forth, I would suggest that the best way for you to proceed here is to: 1. Ask the chairs to re-state the previous consensus. If I misunderstood, then that's easy. 2. If you're still not happy, then you could ask the chairs to re-assess the currnet consensus. 3. If you're still not happy, and you believe this violates 2119, then you can of course appeal. This of course also goes for people who think we should re-allow compression. Best, -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
