Re: [TLS] TLS 1.3 - Support for compression to be removed

"Short, Todd" <tshort@akamai.com> Wed, 07 October 2015 21:28 UTC

Return-Path: <tshort@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58D21B310B for <tls@ietfa.amsl.com>; Wed, 7 Oct 2015 14:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.721
X-Spam-Level:
X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zbqbc-eIzzGB for <tls@ietfa.amsl.com>; Wed, 7 Oct 2015 14:28:32 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id AD2211B30F7 for <tls@ietf.org>; Wed, 7 Oct 2015 14:28:32 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E2CA0200041; Wed, 7 Oct 2015 21:28:31 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id CAB5520002D; Wed, 7 Oct 2015 21:28:31 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1444253311; bh=EASXD6Buim8j3XV7g7vSU5CvQngtnEg6yV59FcCbe6U=; l=14795; h=From:To:CC:Date:References:In-Reply-To:From; b=KwZkpQl0qNBaN5+A6lMJ7D+8WAu5UzkrJ0oZL38xeTXTfaFL5gaz+VQlZ/1iZ2lfl shdJJgdEnqn7XmJ49CsGzbNclte+H7p0QxUg5BDSbef+oPLnQaTULapCxqXLX7zSZM Mybrx/RZ4z0nnMCJlYO/s7gS8KbsG4O+M2/Q/iyc=
Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 9B16D1E0AC; Wed, 7 Oct 2015 21:28:31 +0000 (GMT)
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 7 Oct 2015 16:28:31 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1076.000; Wed, 7 Oct 2015 16:28:30 -0500
From: "Short, Todd" <tshort@akamai.com>
To: Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [TLS] TLS 1.3 - Support for compression to be removed
Thread-Index: AQHRATmlz8vkrT+RfEa++i1UEDH43Z5g0u4AgAAIBoCAAADdAIAAA8SA
Date: Wed, 7 Oct 2015 21:28:29 +0000
Message-ID: <49943603-287F-4C78-AEC1-45628554C190@akamai.com>
References: <CABcZeBNfFHR3eDi1yoifOuZ_ALMPN+xRo1nBx+qk19J+LQjmLw@mail.gmail.com> <20151007211155.384AC1A2C5@ld9781.wdf.sap.corp> <CABcZeBPoF9Qm=ySx+xXkLCegWn1j=06LP+KPcZ=6N7NAbodBew@mail.gmail.com>
In-Reply-To: <CABcZeBPoF9Qm=ySx+xXkLCegWn1j=06LP+KPcZ=6N7NAbodBew@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.43.61]
Content-Type: multipart/alternative; boundary="_000_49943603287F4C78AEC145628554C190akamaicom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/r48AQhnosOVHHLxrxAmsu9laKww>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Oct 2015 22:17:21 -0000

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.

--
-Todd Short
// tshort@akamai.com<mailto:tshort@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 <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:



On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex <mrex@sap.com<mailto:mrex@sap.com>> wrote:
Eric Rescorla wrote:
> Martin Rex <mrex@sap.com<mailto:mrex@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<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls