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

Watson Ladd <watsonbladd@gmail.com> Fri, 09 October 2015 20:15 UTC

Return-Path: <watsonbladd@gmail.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 B1A171B2CFD for <tls@ietfa.amsl.com>; Fri, 9 Oct 2015 13:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 NEuRIk697GSI for <tls@ietfa.amsl.com>; Fri, 9 Oct 2015 13:15:46 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B40C1B2CFA for <tls@ietf.org>; Fri, 9 Oct 2015 13:15:46 -0700 (PDT)
Received: by wicfx3 with SMTP id fx3so80977690wic.0 for <tls@ietf.org>; Fri, 09 Oct 2015 13:15:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y7TQn6fdIu4Gt+ewUV9cYym/Ke+bKu/bc+5XBKMKrBA=; b=NTA55QUCkIeQjtOxyiROYqeeaLqpU03vN1Hr0AEWq3bD30bnkonLiKtz+baKWH8W7Q VnOInNOhTzjYkwaQMUT6r6gvsLQhcyeGeqvfNFpj/PsU0H74muQ5sWe8hSsVuFfsYMWv WWVO4kY7d1EuWjdWlQc5eEFMSqHteXTC0uFiKxFXbxa3Y3dAgX+ljObml15y10ubqmZ3 EgpE3evCt9YBnZNInCS5yoxRAoMhtgjGWWKDG3E2tMotIG2/ocj+m8VFRMepLnita5Vw +UtaT5sRyW4xN71utM/85CiTcOZCYDJ34px2SgGINgh5JTPaIKKJKX6Y/imDUWhFV+32 74Bg==
MIME-Version: 1.0
X-Received: by 10.194.175.232 with SMTP id cd8mr17968930wjc.45.1444421744791; Fri, 09 Oct 2015 13:15:44 -0700 (PDT)
Received: by 10.28.51.145 with HTTP; Fri, 9 Oct 2015 13:15:44 -0700 (PDT)
In-Reply-To: <20151009201405.707081A2D3@ld9781.wdf.sap.corp>
References: <CAOgPGoAYBsr7FsACe1bF0VKs_x+uS+kA_LO9b7xrg6fKGVUuwQ@mail.gmail.com> <20151009201405.707081A2D3@ld9781.wdf.sap.corp>
Date: Fri, 09 Oct 2015 16:15:44 -0400
Message-ID: <CACsn0ckdF8cHC84UBydtkFCO79kratbdU2XeQrUD8PvnUtBvLg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/dtWcFZZA8-9iMEQYQS2GdlniMOo>
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: Fri, 09 Oct 2015 20:15:47 -0000

On Fri, Oct 9, 2015 at 4:14 PM, Martin Rex <mrex@sap.com> wrote:
> 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.

Why is it important that clients be permitted to signal support for
compression and TLS 1.3 conditionally? Remember, we also want to phase
out the use of compression in TLS 1.2.