IETF Logo Mail Archive

Re: [TLS] Remove deprecated fields in TLS 1.3

Arnaud Venturi <arnaud.venturi@rez-gif.supelec.fr> Tue, 04 April 2017 08:58 UTC

Return-Path: <arnaud.venturi@rez-gif.supelec.fr>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBBC1273B1 for <tls@ietfa.amsl.com>; Tue, 4 Apr 2017 01:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 9Z4AsrJzAXFg for <tls@ietfa.amsl.com>; Tue, 4 Apr 2017 01:58:39 -0700 (PDT)
Received: from vader.rez-gif.supelec.fr (mail.rez-gif.supelec.fr [160.228.154.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DEA5128708 for <tls@ietf.org>; Tue, 4 Apr 2017 01:58:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by vader.rez-gif.supelec.fr (Postfix) with ESMTP id D6E3141B20 for <tls@ietf.org>; Tue, 4 Apr 2017 10:58:36 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at vader.rez-gif.supelec.fr
Received: from vader.rez-gif.supelec.fr ([127.0.0.1]) by localhost (mail.rez-gif.supelec.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4AyjVW9agr4 for <tls@ietf.org>; Tue, 4 Apr 2017 10:58:36 +0200 (CEST)
Received: from [10.66.0.230] (unknown [103.246.99.49]) (Authenticated sender: arnaud.venturi) by vader.rez-gif.supelec.fr (Postfix) with ESMTPSA id 97CF241AA7 for <tls@ietf.org>; Tue, 4 Apr 2017 10:58:35 +0200 (CEST)
References: <1e493a03-6843-9afa-fbcb-e8659f0f4184@rez-gif.supelec.fr> <bd54999b-660c-ce6c-5a90-8ce973139a3e@akamai.com> <CAF8qwaD8aXOSaYEkNC7hKNR=qHO6vwQZ27fQA1TvEjSU-bm5Ag@mail.gmail.com> <CABcZeBONoftkU4ee5NssE4KL+qAxBu5E+Dra5pucE5BPDnvdaw@mail.gmail.com>
From: Arnaud Venturi <arnaud.venturi@rez-gif.supelec.fr>
To: tls@ietf.org
Message-ID: <c1639aba-a86a-f133-737c-75a01b527253@rez-gif.supelec.fr>
Date: Tue, 04 Apr 2017 18:58:33 +1000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBONoftkU4ee5NssE4KL+qAxBu5E+Dra5pucE5BPDnvdaw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------75FFF0815A6116D47D84516D"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/eVRQQepJM_t_eVFKfDfmS_1sXXc>
Subject: Re: [TLS] Remove deprecated fields in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 04 Apr 2017 08:58:43 -0000

This was infact the idea, even I thought of the gain much more in terms
of removing something useless than in gaining a few bytes.

Anyway, thanks for your opinions and your time !


-- 
Arnaud

On 04/04/2017 03:10 AM, Eric Rescorla wrote:
> I agree with David. This seems like a low value change
>
> On Mon, Apr 3, 2017 at 9:36 AM, David Benjamin <davidben@google.com
> <mailto:davidben@google.com>> wrote:
>
>     On Mon, Apr 3, 2017 at 12:29 AM Benjamin Kaduk <bkaduk@akamai.com
>     <mailto:bkaduk@akamai.com>> wrote:
>
>         On 04/02/2017 03:33 AM, Arnaud Venturi wrote:
>>         I could not think of any security or interoperability issue with this
>>         proposal, the only drawback I can see being the slight complexity added
>>         in ClientHello parsing.
>
>         The ClientHello message needs to be interpreted in the same
>         way by TLS servers running all versions of TLS.  A TLS 1.0
>         server would not know to use the changed interpretation of the
>         fields and would fail to negotiate a connection.  Basically,
>         no change in the format is possible while preserving the
>         backwards and forwards compatibility of version negotiation.
>
>
>     I believe the idea is that, if you support TLS 1.2 and below, you
>     send a 1.2-compatible ClientHello. If you don't, then you send the
>     proposed ClientHello. Servers would be required to support both
>     formats.
>
>     This change would save us all of 3 bytes in the ClientHello, so my
>     feeling is this isn't worth the trouble of having two formats and
>     all the trouble that entails. (Servers having to parse both
>     formats, code in servers that won't be exercised for years,
>     clients worrying about whether servers implemented that, etc.)
>
>     David
>
>     _______________________________________________
>     TLS mailing list
>     TLS@ietf.org <mailto:TLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tls
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>

v2.23.0 | Report a Bug | By Email