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

Scott Schmit <i.grok@comcast.net> Sat, 03 December 2016 03:58 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 5E6371295A2 for <tls@ietfa.amsl.com>; Fri, 2 Dec 2016 19:58:09 -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 BopmWP4NIOVD for <tls@ietfa.amsl.com>; Fri, 2 Dec 2016 19:58:07 -0800 (PST)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 741B612959B for <tls@ietf.org>; Fri, 2 Dec 2016 19:58:07 -0800 (PST)
Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-03v.sys.comcast.net with SMTP id D1SXcvhd5MppVD1SgcBwYE; Sat, 03 Dec 2016 03:58:06 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1480737486; bh=ztRkQO5zRftppY3UICY2w8LS3J3s5lfbhzuSq2fX64A=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=VNRr5WYq/1RVkFXVo2vpdacYswXeNN/kFhNWzWFGHps59BJk1l9bDd/u7WtiJudZT Rxz1kqOa9Jj5tSA3KsN6fyQ91Sk9g1nLdkGQjiKTCSdUvTSPwHrru++Hkllv6NcHeD AnLxfsGj/fdXeklhSAu2pY9h6ud2K+GWk5sH8evhMCCq337TOmBYOSPaYiU0G2EumD 5AFgY/A6I7Q1DSCpuz+tlaMWjAY4nRnYjCGeRemNvSezVTi7s7I494FZ1jyEmAsTQ+ nLCu/fJfRm+gh2e8ohXBoqFR2bjxLquQ37y3AYREh383nij+HTkATYsMR1M3o85NCU 6Y0QzhEt2XEMA==
Received: from odin.ULTHAR.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by resomta-ch2-08v.sys.comcast.net with SMTP id D1SVcIlzoLEc2D1SacIJ5e; Sat, 03 Dec 2016 03:58:04 +0000
Received: from odin.ULTHAR.us (localhost [127.0.0.1]) by odin.ULTHAR.us (8.15.2/8.14.5) with ESMTP id uB33vssj027604 for <tls@ietf.org>; Fri, 2 Dec 2016 22:57:54 -0500
Received: (from draco@localhost) by odin.ULTHAR.us (8.15.2/8.15.2/Submit) id uB33vshk027603 for tls@ietf.org; Fri, 2 Dec 2016 22:57:54 -0500
Date: Fri, 02 Dec 2016 22:57:54 -0500
From: Scott Schmit <i.grok@comcast.net>
To: tls@ietf.org
Message-ID: <20161203035754.GA27160@odin.ulthar.us>
References: <CF83FAD0-B337-4F9E-A80B-2BAA6826BF41@sn3rd.com> <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> <310c930ad6264e49b6c6862d99b63ef0@usma1ex-dag1mb1.msg.corp.akamai.com> <2394990.KnQcpSKGuD@pintsize.usersys.redhat.com> <CAPt1N1kV-eSdcbkK+ig+fisWuWVop_vvosm5N24iLh1KBTcf+w@mail.gmail.com> <CADwHJ+9Ug7KVyXZf3=QEwcvkiFrWDCReSjG5Ty=ZkDnw8e-M=A@mail.gmail.com> <1480713686960.84870@cs.auckland.ac.nz> <CAHOTMV+=Yh9ZRRNuHs4xF8z7fweh4syU4qi7MT4x=R78sGqLbQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha-256"; boundary="vkogqOf2sHV7VnPd"
Content-Disposition: inline
In-Reply-To: <CAHOTMV+=Yh9ZRRNuHs4xF8z7fweh4syU4qi7MT4x=R78sGqLbQ@mail.gmail.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-CMAE-Envelope: MS4wfP3dVyxAoSUzgaOW3FNHEe4VIhc4Hb1wYQdi1Ru4r8a/dH1WnwjwnThSFuV0RHqZnNxzZVINOW34qoJ6+sqYVlGEMr8xIBdtdCZ45E02oOMJ4NiBitP8 eu/b8zwMO7ewsiPnAnHgSQoAn3Fh/AH2YNU=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3X5ia7NASvlWQFjBanSYTLrXi_8>
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 03:58:09 -0000

On Fri, Dec 02, 2016 at 02:16:16PM -0800, Tony Arcieri wrote:
> On Fri, Dec 2, 2016 at 1:21 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz>
> wrote:
> 
> > The change was proposed long ago, and deferred by the chairs until now.
> > This
> > is just another variant of the inertia argument.
> 
> 
> You keep dismissing this argument out of hand, but I think it has merit.
> 
> I think we can all admit the decision to rename SSL -> TLS is a mistake (to
> the point people are proposing to retroactively re-rename TLS back to SSL).
> 
> There is now a huge body of work which calls the protocol "TLS 1.3" which
> will be cited for years to come. You wrote this whole body of work off as
> the concern of "TLS WG and a small number of people who interact with it"
> as if a move to a different version number comes at zero cost almost as if
> this work doesn't matter, but I have a different view: this is one more bit
> of errata in exactly the same vein as the SSL -> TLS move which anyone
> consulting this body of work will have to contend with.
> 
> You will no doubt disagree, so I'm simply saying it for posterity: keeping
> the version TLS 1.3 is the least confusing option, IMO.

SSL 3.0 was defined in November 1996 (20 years ago).
RFC 7568 (sslv3diediedie) was published in June 2015.
That's about 18.5 years.

TLS 1.0 is still in use, it was standardized in January 1999.
It's not dead yet, but there has been talk of it.
That's almost 18 years ago.

So these protocols tend to last multiple decades (granted, this is a
small sample size, but it's what we've got).

This draft has been in development since April 2014, 2.6 years ago.
Over that time, the wire protocol has changed multiple times and
incompatibly.  So not even all of that 2.6 years of details is still
applicable to the protocol we're going to publish as an RFC.  So why
would mixing up searched for the final protocol with the draft versions
be a good thing?  

Development versions get new names when they get delivered all the time.
Frankly, at $DAYJOB, development versions are always different than the
final delivered version, by definition.  Doing otherwise is poor version
control.

The volume of work that will be published in the hopefully 18 or more
years that this draft is in deployment will dwarf the current body of
work.  If it doesn't, then we will have completely failed.

Finally, at the top of every internet draft, the IETF states:
> Internet-Drafts are draft documents valid for a maximum of six months
> and may be updated, replaced, or obsoleted by other documents at any
> time.  It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress."

So, no, we have *not* been calling the next version of TLS "TLS 1.3" for
2.6 years.  We have been calling it "a work in progress, subject to
change at any time."  Anyone doing otherwise is arguably as confused as
those who don't even know what TLS is.  And there are a lot more of the
latter than the former.

But no, I would not support calling the next TLS version "SSL 4/2017" -- the
harm of invalidating the "SSL is broken, TLS is (more) secure" advice is
too great. I'd support calling it RSSL (really secure ...) before I'd
support that.

-- 
Scott Schmit