Re: [TLS] Confirming consensus: TLS1.3->TLS*

Scott Schmit <i.grok@comcast.net> Sat, 03 December 2016 04:02 UTC

Return-Path: <i.grok@comcast.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 83B8D1295A5 for <tls@ietfa.amsl.com>; Fri, 2 Dec 2016 20:02:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.596
X-Spam-Level:
X-Spam-Status: No, score=-5.596 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 kF6TysOsAAAj for <tls@ietfa.amsl.com>; Fri, 2 Dec 2016 20:02:53 -0800 (PST)
Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8281295A1 for <tls@ietf.org>; Fri, 2 Dec 2016 20:02:53 -0800 (PST)
Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-05v.sys.comcast.net with SMTP id D1XDc2YWrGIG7D1XJchdtO; Sat, 03 Dec 2016 04:02:53 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1480737773; bh=iRwjHSBHgw0STX1LXCUljlslweT92HXb6hko22NrVas=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=Yjp4vAdL9sUhhbItivlLexr5/NmUSfUT/iToVs4JZGsph2Wl728Ec9i6fBVgqSYAp 4UcvCTdTR04kRmHYUK4nfzCfL+xos1Od/K+MWv1d+sjfysrESp2D9+TM69fZ8kuY3n zojMyF8xqbbzEC0XD1qpt9NhxwHudVtRoTNN0kUaDxrD6Lpo4jBmp/FjUGumbr3dWT IAqzGWJyuIgBbUFcv9Ajqq6xuWefFB1anauHAgt+Ud6+iV+oBanwHS1hw5HIKi7reV u8/78oLMUUlCRXI5FY/Av3aAzRIJ5rw1LZkH+OviUxpg521XK7oyPByWx7BCCLeGZR zYszvkd369Asw==
Received: from odin.ULTHAR.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by resomta-ch2-08v.sys.comcast.net with SMTP id D1X8cImvjLEc2D1XCcIJRv; Sat, 03 Dec 2016 04:02:51 +0000
Received: from odin.ULTHAR.us (localhost [127.0.0.1]) by odin.ULTHAR.us (8.15.2/8.14.5) with ESMTP id uB342fvW027656 for <tls@ietf.org>; Fri, 2 Dec 2016 23:02:41 -0500
Received: (from draco@localhost) by odin.ULTHAR.us (8.15.2/8.15.2/Submit) id uB342fwP027654 for tls@ietf.org; Fri, 2 Dec 2016 23:02:41 -0500
Date: Fri, 02 Dec 2016 23:02:41 -0500
From: Scott Schmit <i.grok@comcast.net>
To: tls@ietf.org
Message-ID: <20161203040241.GB27160@odin.ulthar.us>
References: <CF83FAD0-B337-4F9E-A80B-2BAA6826BF41@sn3rd.com> <FDFEA8C9B9B6BD4685DCC959079C81F5E1913B9D@BLREML509-MBX.china.huawei.com> <CAOjisRy+Lt59rE-+_bJmD=0oQD+qbeUBsJQyOvH6OggfhqyYqg@mail.gmail.com> <1480566504487.58214@cs.auckland.ac.nz> <D538A9AE-7F5A-4A70-8EED-F7D4426CE087@dukhovni.org> <CAHOTMVJzvf8v0S3vhFASekd6ksut0uNBhJDmuYzSQcJfy6JYpg@mail.gmail.com> <1480648354917.41781@cs.auckland.ac.nz> <CAF8qwaAMcLQYhTVGnPA-=b-L1vmkyhKGPM39QV4+VvPf9GKkbQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha-256"; boundary="lEGEL1/lMxI0MVQ2"
Content-Disposition: inline
In-Reply-To: <CAF8qwaAMcLQYhTVGnPA-=b-L1vmkyhKGPM39QV4+VvPf9GKkbQ@mail.gmail.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-CMAE-Envelope: MS4wfGqdZLYh8kE1xhIw06EHXrw8vvBYt76Q68zT3KXNXXyipT2GFccTnabvrsGvjOHDLJQb5190B3udjwEAz8vDHOrD8g60m90YDedNknwXW6IqCyLMTZ1p GCU99rX8+NEoAP/O0l8ssNrVtMxG5ipgJrI=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Sivj0j9VOxLIzpwXMx-R8b7pTlI>
Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS*
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: Sat, 03 Dec 2016 04:02:55 -0000

On Fri, Dec 02, 2016 at 03:35:00AM +0000, David Benjamin wrote:
> I think TLS 4 makes everything worse, not better.
> 
> In hindsight, renaming SSL 3.1 was a terrible mistake. But TLS 1.2 is going
> to exist for a long time. If we call the next one 4, we have to explain a
> gap in the versioning (1.0, 1.1, 1.2, 4?) and placing 2.0 and 3.0 after 1.2
> becomes even more inviting.
> 
> Short of a time machine so we can call this SSL 3.4, the best fix is to let
> SSL 3.0 fall away. This is already semi-plausible (it's out of all
> browsers) and is only going to become more realistic over time. Certainly
> it will be faster than TLS 1.2 going away and undoing TLS 4's version gap
> problem. (TLS 1.3 even places SSL 3.0 as a MUST NOT, for what little teeth
> that has.)
> 
> Once SSL 3.0 falls away, we'll be left with 1.0, 1.1, 1.2, and 1.3, which
> is a plausible numbering progression. There'll still be the mess with SSL
> being the informal name for the protocol family, but that isn't a numbering
> problem.

Then "TLS 2017" should be even better.  It's neither < 3 nor similar
enough to SSL versions as to be confused with them.

And the shift in versioning strategy is so typical it would probably not
even draw serious notice.

-- 
Scott Schmit