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.
>
>> 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"
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.
-Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
