IETF Logo Mail Archive

Re: [TLS] TLS 1.3 -> TLS 2.0?

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 31 August 2016 14:09 UTC

Return-Path: <dkg@fifthhorseman.net>
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 3FFFF12DC0D for <tls@ietfa.amsl.com>; Wed, 31 Aug 2016 07:09:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level:
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SUBJ_ALL_CAPS=1.506] autolearn=no 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 CgTxNdiA-bjZ for <tls@ietfa.amsl.com>; Wed, 31 Aug 2016 07:09:41 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8559712DC7C for <tls@ietf.org>; Wed, 31 Aug 2016 06:53:46 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 8D918F98B; Wed, 31 Aug 2016 09:53:45 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id A03C2201E8; Tue, 30 Aug 2016 17:21:24 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Hubert Kario <hkario@redhat.com>, tls@ietf.org
In-Reply-To: <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com>
References: <201608301419.33620.davemgarrett@gmail.com> <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com>
User-Agent: Notmuch/0.22.1+88~g8d09e96 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Tue, 30 Aug 2016 17:21:21 -0400
Message-ID: <878tvex8a6.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OUgSJBxiC92Mm9kR0-DYdznTLXw>
Subject: Re: [TLS] TLS 1.3 -> TLS 2.0?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 31 Aug 2016 14:09:46 -0000

On Tue 2016-08-30 16:14:06 -0400, Hubert Kario wrote:
> On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote:
>> * Keep the version ID as { 3, 4 } (already weird counting; changing risks
>> more intolerance) 
>
> IMNSHO this alone is enough of a reason not to do this
>
> it's enough explaining to people that SSLv3.3 is really TLSv1.2, now we'll 
> have SSLv3.4 == TLSv1.3 == TLSv2.0
>
> it's silly at this point

Who are you talking to who's fine with looking at the bytes on the wire
but isn't fine with understanding that a 16-bit field might not map
directly to our imagination of decimal?

If that mapping really matters, We could combine this with Erik Nygren's
version inflation suggestion and just jump straight to TLS 34 :P

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
doesn't have a "TLS version" registry.  Would it be simpler to have IANA
create that and just populate it with:

  Value | Description | Reference
  ------+-------------+----------
   0x30 |    SSLv3    | RFC 6101, RFC 7568
   0x31 |   TLSv1.0   | RFC 2246
   0x32 |   TLSv1.1   | RFC 4346
   0x33 |   TLSv1.2   | RFC 5246
   0x34 |    TLSv4    | RFC XXXX


Then you could tell people to just look it up in the table.

        --dkg, tongue only marginally in cheek

v2.23.0 | Report a Bug | By Email