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

Dan Brown <danibrown@blackberry.com> Fri, 25 November 2016 15:02 UTC

Return-Path: <danibrown@blackberry.com>
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 24185129854 for <tls@ietfa.amsl.com>; Fri, 25 Nov 2016 07:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.098
X-Spam-Level:
X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-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 za7CA74rNLWV for <tls@ietfa.amsl.com>; Fri, 25 Nov 2016 07:02:31 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1BD129FD4 for <tls@ietf.org>; Fri, 25 Nov 2016 06:43:35 -0800 (PST)
Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs213cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Nov 2016 09:43:33 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0319.002; Fri, 25 Nov 2016 09:43:33 -0500
From: Dan Brown <danibrown@blackberry.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS*
Thread-Index: AQHSQUFZSX3LzrapIkar/s/Es63GbKDi+vqAgALvxwCAA9j5oA==
Date: Fri, 25 Nov 2016 14:43:32 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF501083213@XMB116CNC.rim.net>
References: <CF83FAD0-B337-4F9E-A80B-2BAA6826BF41@sn3rd.com> <CABcZeBN+QLeh=06PwATcK_98znR5UYkxs14e0TA3N5i5_pWOZg@mail.gmail.com> <201611221706.50692.davemgarrett@gmail.com>
In-Reply-To: <201611221706.50692.davemgarrett@gmail.com>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.246]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/h0wPFgz-t8-8WJRWjuM8L2XXEGw>
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: Fri, 25 Nov 2016 15:02:36 -0000

I don't oppose any of the 4 given options, but I slightly prefer TLS 2.0, it seems simple and clear.  

In my opinion, the whole SSL vs TLS confusion needs better education to confront, version numbers (even dates) alone might not be enough.  Renaming *SSL products to *TLS should help.  Avoiding "SSL/TLS" might help.

Since others have proposed new options, how about TLS 2.017? Using the date has benefits, but the actual crypto changes are much more important, so the decimal makes that point.  An old crypto principle is that older is better (among equally unbroken options) -- but naming new stuff is just not enough to rid us of broken old stuff, so putting dates in names might not undermine this principle.  For future naming, on minor changes (or even pre-scheduled reviews with no changes), update the date part, on major changes, start from scratch (as in 3.2024, or even use different letters ... ).  

By the way, I'm sorry if my opinion diverges from the currently forming consensus.

Just my $0.02.
  
Dan

PS Just to be clear, if votes are to be tallied, my vote on this issue should be weighted quite low (i.e. 0, unless other votes are weighted low too, and some kind of tie-breaker is needed), for at least three reasons: I have not followed the TLS 1.3/2.0 spec closely (i.e., I had no part in building the shed); I have nearly zero experience dealing with user interpretation (i.e. marketing) of protocol names; my preference is weak. (Enough to deserve a negative weight, if that were not cheatable;)

PPS I've said before that I prefer TLC(rypto) to TLS(ecurity), but that's unlikely to fly, and it may be okay to grandfather this tradition.  (I hope names of future crypto protocols (that TLS WG might work on) can be more specific and realistic.)

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Dave Garrett
Sent: Tuesday, November 22, 2016 5:07 PM
To: tls@ietf.org
Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS*

(replies to a bunch of ideas in this thread)

As the person who lit the match under this latest bikeshed debate, personally, I don't see a strong consensus building here. Leaving the bikeshed unpainted seems like the option we're headed for, at this rate. I'm fine with TLS 1.3 if that's the result here.

That said, I think I've been somewhat swayed to the TLS 4 camp with the "fourth version of TLS" message. It makes a kind of messy sense that's kind of fitting for TLS. I'm no longer against it.

I've also suggested highlighting the year in the past, but only in the context of the title and messaging, not actually replacing the version number itself. I'd be ok with TLS 1.3-2017 (or something), not doing a find/replace of 1.3 and changing it to 2017, wholesale. That just feels even more confusing.

Lastly, I am vehemently against the suggestion of ditching the TLS name in favor of SSL again, as was also brought up in this thread. SSL is dead and insecure, and that message needs to stay. We need to get people to stop conflating the two and making this worse, not accepting it.


Dave


On Sunday, November 20, 2016 08:16:07 pm Eric Rescorla wrote:
> I mildly prefer TLS 1.3 to TLS 2 and TLS 4 (If we're going to rev the 
> major version number we should abandon the minor one).
> TLS 2017 strikes me as quite bad; we're certainly not planning to do a 
> TLS 2018. I am strongly opposed to TLS 2017.
> 
> -Ekr
> 
> 
> On Fri, Nov 18, 2016 at 11:12 AM, Sean Turner <sean@sn3rd.com> wrote:
> 
> > At IETF 97, the chairs lead a discussion to resolve whether the WG 
> > should rebrand TLS1.3 to something else.  Slides can be found @
> > https://www.ietf.org/proceedings/97/slides/slides-
> > 97-tls-rebranding-aka-pr612-01.pdf.
> >
> > The consensus in the room was to leave it as is, i.e., TLS1.3, and 
> > to not rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm 
> > this decision on the list so please let the list know your top choice between:
> >
> > - Leave it TLS 1.3
> > - Rebrand TLS 2.0
> > - Rebrand TLS 2
> > - Rebrand TLS 4
> >
> > by 2 December 2016.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls