On Wed, Oct 7, 2015 at 11:28 PM, 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. > > 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. -Ekr -- > -Todd Short > // tsh...@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Oct 7, 2015, at 5:15 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex <m...@sap.com> wrote: > >> Eric Rescorla wrote: >> > Martin Rex <m...@sap.com> wrote: >> >> Eric Rescorla wrote: >> >>> >> >>> That is what the document says: >> >>> "Versions of TLS before 1.3 supported compression and the list of >> >>> compression methods was supplied in this field. 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. 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." >> >> >> >> The quoted wording calls for a fatal handshake failure when ClientHello >> >> offers >> >> >> >> TLSv1.2+compression _or_ TLSv1.3 >> >> >> >> while at the same time the last requirement asserts that a ClientHello >> with >> >> >> >> TLSv1.2+compression >> >> >> >> is perfectly OK. To me, this looks quite odd. >> > >> > That's not how I read this text. >> > >> > Rather, I read it as: >> > If ClientHelloVersion >= TLS 1.3 >> > then the compression field must be empty >> > else: >> > the compression field is dictated by other versions >> > >> > This doesn't seem inconsistent to me. If you still think that the >> paragraph >> > reads differently, can you help me by diagramming it? >> >> What you describe would be considerable worse that what I understood, >> because it would mean that a TLSv1.3 ClientHello will be unconditionally >> invalid for a TLSv1.2 server. >> >> https://tools.ietf.org/html/rfc5246#page-42 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5246-23page-2D42&d=BQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=IxUTnzF6SN6y6C4zTXXfgQmiV1FojXWtLZ0S8hS5eGY&s=Uu3NPBs1t52N_fGVGPqXazTAStG7cPUeCfNh6eCTtkk&e=> >> >> compression_methods >> This is a list of the compression methods supported by the client, >> sorted by client preference. If the session_id field is not empty >> (implying a session resumption request), it MUST include the >> >> Dierks & Rescorla Standards Track [Page 41] >> >> RFC 5246 TLS August 2008 >> >> *> compression_method from that session. This vector MUST contain, >> *> and all implementations MUST support, CompressionMethod.null. >> Thus, a client and server will always be able to agree on a >> compression method. > > > Sorry, I spoke carelessly. It must contain solely the null method. > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
