Joseph Salowey wrote:
>
> The chairs have read through this thread and do not see any new information
> that would cause the working group to reconsider the decision to remove
> compression from TLS 1.3.
I am (and I was) perfectly fine with removing compression from TLSv1.3.
(btw. our own implementation never implemented TLS compression).
>
> Discussions about clarifying the language and
> intent of the document are OK.
But in the previous discussion only Todd Short seems to understand, why I am
objecting to one specific requirement in the current plan to achieve
removal of compression from TLSv1.3.
>>>
>>> A ClientHello with
>>>
>>> ClientHello.client_version = (3,3)
>>> ClientHello.compression_methods = (DEFLATE(1),null(0))
>>>
>>> will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers.
>>>
>>>
>>> ClientHello.client_version = (3,4)
>>> ClientHello.compression_methods = (DEFLATE(1),null(0))
>>>
>>> will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers,
The issue is about the TLSv1.3 server response for the second case above.
If we want to have compression removed from TLSv1.3, then my suggested
wording would be sufficient, and provide proper and robust negotiation
of TLS protocol options:
All TLS protocol
versions require the "null" compression method MUST be included/present
in the compression_methods list of ClientHello. A TLSv1.3 server that
is offered and selects/negotiates protocol version TLSv1.3, MUST select
the "null" compression method, and MUST ignore all other compression
methods that might appear in the compression_methods list of ClientHello.
The (current) text, which Eric quoted, on the other hand:
For any TLS 1.3
ClientHello, this field MUST contain only the ?null? compression method
with the code point of 0. If a TLS 1.3 ClientHello is received with any
other value in this field, the server MUST generate a fatal
'illegal_parameter' alert.
would require a TLSv1.3 server to unconditionally abort the TLS handshake
rather than to negotiate the "null" compression and continue the handshake.
The original intent of the ClientHello & ServerHello handshake messages
is negotiation of TLS protocol parameters, and choking&aborting rather
than performing selection&negotiation of the desired protocol options
is what we see in the installed base in form of "TLS version intolerance"
and "TLS extensions intolerance", and what caused browser implementors
to come up with an insecure&dangerous scheme known as "downgrade dance",
which was demonstrated to be a bad idea, because it is what made POODLE
possible in the first place.
The proposed "choke on everything but compression_method = (0)" rather
than "you MUST select the null compression method for TLSv1.3" is
particularly weird due to the statement that follows the current text:
Note that TLS 1.3 servers may receive TLS 1.2
or prior ClientHellos which contain other compression methods and MUST
follow the procedures for the appropriate prior version of TLS.
-Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
