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

Hubert Kario <hkario@redhat.com> Wed, 31 August 2016 10:47 UTC

Return-Path: <hkario@redhat.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 38D0712D14A for <tls@ietfa.amsl.com>; Wed, 31 Aug 2016 03:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.964
X-Spam-Level:
X-Spam-Status: No, score=-5.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] 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 Fy_TnEHf3RFe for <tls@ietfa.amsl.com>; Wed, 31 Aug 2016 03:47:20 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA94E12D137 for <tls@ietf.org>; Wed, 31 Aug 2016 03:47:20 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9B8078553E; Wed, 31 Aug 2016 10:47:20 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7VAlJh2008427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Aug 2016 06:47:20 -0400
From: Hubert Kario <hkario@redhat.com>
To: Xiaoyin Liu <xiaoyin.l@outlook.com>
Date: Wed, 31 Aug 2016 12:47:14 +0200
Message-ID: <4549539.ex8BfFD3QY@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.7-300.fc24.x86_64; KDE/5.25.0; x86_64; ; )
In-Reply-To: <CY1PR15MB0778BCCFB5DC5DFB4C21318CFFE30@CY1PR15MB0778.namprd15.prod.outlook.com>
References: <201608301419.33620.davemgarrett@gmail.com> <3453142.248EJ6K14H@pintsize.usersys.redhat.com> <CY1PR15MB0778BCCFB5DC5DFB4C21318CFFE30@CY1PR15MB0778.namprd15.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1813493.Ln0pRTUV2Q"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 31 Aug 2016 10:47:20 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FSOOHImi0rZHHfALVcYs9RZEaDg>
Cc: "tls@ietf.org" <tls@ietf.org>
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 10:47:22 -0000

On Wednesday, 31 August 2016 09:35:47 CEST Xiaoyin Liu wrote:
> > From: Hubert Kario [mailto:hkario@redhat.com]
> > Sent: Wednesday, August 31, 2016 4:48 AM
> > To: Xiaoyin Liu <xiaoyin.l@outlook.com>
> > Cc: tls@ietf.org
> > Subject: Re: [TLS] TLS 1.3 -> TLS 2.0?
> > 
> > On Tuesday, 30 August 2016 22:20:45 CEST Xiaoyin Liu wrote:
> > 
> > > > -----Original Message-----
> > > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Hubert Kario
> > > > Sent: Tuesday, August 30, 2016 4:14 PM
> > > > To: tls@ietf.org
> > > > Subject: Re: [TLS] TLS 1.3 -> TLS 2.0?
> > > >
> > > >
> > > >
> > > > 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
> >  
> > >
> > >
> > >
> > > I don't think this is a problem. People will forget "TLS 1.3" and will
> > > only remember "TLS 2.0" after some time.
> > 
> > 
> > well, that's not the experience of our support engineers, people still
> > confuse
> SSLv3 with TLSv<any>
> 
> 
> It's normal that people confuse SSLv3 with TLS. SSL 3.0 was a released and
> widely deployed protocol, and the term "SSL" is still widely used today to
> refer to TLS. But the situation is much better if we rename TLS 1.3: TLS
> 1.3 spec has not been released, it is not supported by any non-testing
> clients or servers, and there are not many documents, papers or blogs
> mentioning TLS 1.3. This is why I said "TLS 1.3" is similar to "Windows 9"
> in terms of naming.

it's not, Microsoft didn't release anything similar to Windows that would have 
"9" or "10" in the name (even DOS stopped at 6). But there was both SSLv2 and 
SSLv3.

It's closer to the RHL 7 (Red Hat Linux) being confused with RHEL 7 (Red Hat 
Enterprise Linux), and yes, it's still happening

the problem is not that people will not know when you talk about TLSv2.0 you 
mean TLSv1.3 (or vice versa). The problem is that people will think that when 
you talk about TLSv2.0 you mean SSLv2 *because* people use the SSL and TLS 
terms interchangeably!

> > if the WG really wants a TLSvX.0 name, the X really should be bigger than
> > 3
 
> 
> 
> Well, I prefer TLS 2.0, because it sounds more natural that major version 2
> comes after major version 1. But TLS {>3}.0 is also fine to me, if the WG
> thinks people may get confused between SSL 2.0 and TLS 2.0.
 
> Xiaoyin


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic