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

From: Dave Garrett <[email-masked]>
Date: Tue, 30 Aug 2016 14:19:33 -0400

I occasionally see people ask why we're calling it TLS 1.3 when so much has changed, and I used to simply think that it was too bikesheddy to bother changing at this point. However, now that we've redone negotiation, we have new TLS 1.3+ only cipher suites. The old are not compatible with the new (new codepoints needed for old ciphers) and the new are not backwards compatible with the old (they'll just be ignored). We actually risk misconfiguration in the future if the distinction isn't made clear. I think it's time we just renamed TLS 1.3 to TLS 2.0. There are major changes, so labeling it a major version seems more appropriate.

Note that contrary to what some people seem to think, version numbers are not completely without meaning. To someone who doesn't really know/care that much what TLS is, making sure to use the latest major version of a security protocol carries more weight than a minor version. It also makes it clear that there are new features here (e.g. 0-RTT). There's some de facto standardization in versioning which does carry some useful information. We're not just dealing with programmers here; this stuff needs to be clear for managers and non-professionals. If we want to get everyone upgraded eventually, messaging is important.

Specific proposed changes:
* Mass rename TLS 1.3 to TLS 2.0 in all places (or TLS 2)
* Keep the version ID as { 3, 4 } (already weird counting; changing risks more intolerance)
* Rename the new cipher suites to have a "TLS2_" prefix to be less confusing for the registry & end configuration
* Add a sentence noting the development history here, and that all documents that refer to TLS 1.3 refer to TLS 2.0 (e.g. HTTP/2)

This is a relatively simple set of changes to make that I think can be beneficial in the long run, and is essentially just editorial. Rebranding might not be something everyone really wants to bother with, but if we expect this to be in use for a decade or more (whether we like it or not), we should probably make sure to be as clear as possible at the start.

Dave

---

From: Andrei Popov <[email-masked]>
Date: Tue, 30 Aug 2016 18:33:05 +0000

This proposal makes a lot of sense to me. I've had numerous conversations explaining to folks that TLS 1.3 is really TLS 2.0.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Dave Garrett
Sent: Tuesday, August 30, 2016 11:20 AM
To: [email-masked]
Subject: [TLS] TLS 1.3 -> TLS 2.0?

Dave

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Xiaoyin Liu <[email-masked]>
Date: Tue, 30 Aug 2016 18:36:51 +0000

I support this change as long as there is no technical change (version ID remains 0x0304).

Best,

Xiaoyin

From: Dave Garrett<mailto:[email-masked]>
Sent: Tuesday, August 30, 2016 2:19 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [TLS] TLS 1.3 -> TLS 2.0?

Dave

---

From: Dave Garrett <[email-masked]>
Date: Tue, 30 Aug 2016 15:29:49 -0400

> I support this change as long as there is no technical change (version ID remains 0x0304).

To reiterate, I am also against changing the version ID. However, I do think it's worth updating the context string version number, otherwise it'd be a little unnecessarily confusing there. (trivial change to key derivation, but not wire format) I've also made a point to tweak references to the on-the-wire version value to refer to it as a "version ID" rather than just version, to make it very clear that this is really just an arbitrary codepoint and shouldn't be read as 3.4.

I've made the changes for a WIP branch, here (not a PR, as of yet):
https://github.com/tlswg/tls13-spec/compare/master...davegarrett:tls2rebranding

Going through the motions of doing the renaming now is useful to see if there's anything that is more affected than initially expected, such as the context strings having the version in there directly as a string (they're designed to be updated as-needed, so this shouldn't be a problem).

Dave

---

From: Hubert Kario <[email-masked]>
Date: Tue, 30 Aug 2016 22:14:06 +0200

> * Keep the version ID as { 3, 4 } (already weird counting; changing risks

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
-- 
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

---

From: Erik Nygren <[email-masked]>
Date: Tue, 30 Aug 2016 16:20:12 -0400

I'm also very supportive for the reasons you outline.

However, I think we should consider calling it TLS 4 or TLS 4.0 or TLS 5.

In particular, much of the non-technical audience still calls it "SSL" (pet
peeve of many of us, I suspect) and having a version number clearly greater
than SSLv3 and not confusing with SSLv2 would be quite valuable.  "TLS 2"
may have risk for unfortunate confusions with SSLv2 and SSLv3.

Another reason to avoid 1.3 is Western culture negative connotations around
"tls13" which TLS 1.3 will get abbreviated as.

- Erik

     [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]

On Aug 30, 2016 3:35 PM, "Dave Garrett" <[email-masked]> wrote:

> To reiterate, I am also against changing the version ID. However, I do
> think it's worth updating the context string version number, otherwise it'd
> be a little unnecessarily confusing there. (trivial change to key
> derivation, but not wire format) I've also made a point to tweak references
> to the on-the-wire version value to refer to it as a "version ID" rather
> than just version, to make it very clear that this is really just an
> arbitrary codepoint and shouldn't be read as 3.4.
>
> Going through the motions of doing the renaming now is useful to see if
> there's anything that is more affected than initially expected, such as the
> context strings having the version in there directly as a string (they're
> designed to be updated as-needed, so this shouldn't be a problem).
>
>
> Dave
>

---

From: Rob Stradling <[email-masked]>
Date: Tue, 30 Aug 2016 22:04:20 +0100

> have SSLv3.4 == TLSv1.3 == TLSv2.0

It's been silly for nearly two decades already!

https://plus.google.com/+IlyaGrigorik/posts/BesDRVDqB4h

So...

On 30/08/16 21:20, Erik Nygren wrote:
<snip>
>> In particular, much of the non-technical audience still calls it "SSL"
>> (pet peeve of many of us, I suspect) and having a version number clearly
>> greater than SSLv3 and not confusing with SSLv2 would be quite
>> valuable.  "TLS 2" may have risk for unfortunate confusions with SSLv2
>> and SSLv3.

How about we drop the "TLS" name completely, and simply call it "SSLv4" 
or "SSLv5" ?  Then the non-technical audience that still calls it "SSL" 
would magically become correct again.  :-)

Returning to a previous name seems to be trendy at the moment...
https://en.wikipedia.org/wiki/Mac_OS

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Xiaoyin Liu <[email-masked]>
Date: Tue, 30 Aug 2016 22:20:45 +0000

> From: TLS [mailto:[email-masked]] On Behalf Of Hubert Kario
> Sent: Tuesday, August 30, 2016 4:14 PM
> To: [email-masked]
> Subject: Re: [TLS] TLS 1.3 -> TLS 2.0?
> 
> 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. Just like few people still remember "Windows 9" today, even if "Windows 9" had been rumored in the news every day before Microsoft officially announced "Windows 10".

Also this spec hasn't reached WGLC, so I don't think it's too late to make a change to its name.

Xiaoyin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 31 Aug 2016 08:07:25 +0200

On Tue, 2016-08-30 at 14:19 -0400, Dave Garrett wrote:
> I occasionally see people ask why we're calling it TLS 1.3 when so
> much has changed, and I used to simply think that it was too
> bikesheddy to bother changing at this point. However, now that we've
> redone negotiation, we have new TLS 1.3+ only cipher suites. The old
> are not compatible with the new (new codepoints needed for old
> ciphers) and the new are not backwards compatible with the old
> (they'll just be ignored). We actually risk misconfiguration in the
> future if the distinction isn't made clear. I think it's time we just
> renamed TLS 1.3 to TLS 2.0. There are major changes, so labeling it a
> major version seems more appropriate.

I agree with the proposal.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 31 Aug 2016 06:23:57 +0000

Dave Garrett <[email-masked]> writes:

>I think it's time we just renamed TLS 1.3 to TLS 2.0. There are major
>changes, so labeling it a major version seems more appropriate.
>
>[...]

+1 to all of this.  As people on the list know, I've been calling it 
"TLS 2.0-called-1.3" for a long time now.  It really is a new protocol rather
than something in the 1.x family, and it's quite misleading calling it 1.3.

Peter.

---

From: Julien ÉLIE <[email-masked]>
Date: Wed, 31 Aug 2016 09:41:15 +0200

Hi all,

> than something in the 1.x family, and it's quite misleading calling it 

I am also in favour of a TLS 1.3 -> TLS 2.0 renaming.

Considering that possible change, wouldn't it be useful to go on working
on draft-gutmann-tls-lts-05, and consider TLS-LTS not as a TLS extension 
but
as a real 1.3 version of the 1.x series?

-- 
Julien ÉLIE

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 31 Aug 2016 07:52:44 +0000

Julien ÉLIE <[email-masked]> writes:

>Considering that possible change, wouldn't it be useful to go on working on
>draft-gutmann-tls-lts-05, and consider TLS-LTS not as a TLS extension but as
>a real 1.3 version of the 1.x series?

If the current 2.0-called-1.3 is renamed to 2.0, I'd be open to calling LTS
"1.3", although I think it's more a 1.2.1 :-).  Its real goal though is to be
exactly what it says on the label, an LTS version of the TLS 1.x line that can
be used in devices with long lifecycles that are based on the 1.x family and
need a best-of-breed version of that.  So LTS would be the final, wrap-up
version of the 1.x line for people who need, well, an LTS version of the
protocol.

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 31 Aug 2016 10:47:59 +0200

On Tuesday, 30 August 2016 22:20:45 CEST Xiaoyin Liu wrote:
> 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>

if the WG really wants a TLSvX.0 name, the X really should be bigger than 3

---

From: Xiaoyin Liu <[email-masked]>
Date: Wed, 31 Aug 2016 09:35:47 +0000

> From: Hubert Kario [mailto:[email-masked]]
> Sent: Wednesday, August 31, 2016 4:48 AM
> To: Xiaoyin Liu <[email-masked]>
> Cc: [email-masked]
> > I don't think this is a problem. People will forget "TLS 1.3" and will
> > only remember "TLS 2.0" after some time.
> 

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.

> 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

---

From: Hubert Kario <[email-masked]>
Date: Wed, 31 Aug 2016 12:47:14 +0200

On Wednesday, 31 August 2016 09:35:47 CEST Xiaoyin Liu wrote:
> 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!

> 
> 
> 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.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 30 Aug 2016 17:21:21 -0400

> have SSLv3.4 == TLSv1.3 == TLSv2.0

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 31 Aug 2016 14:25:37 +0000

>   Value | Description | Reference

YES.  Do this no matter what the last Description value ends up being.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Yoav Nir <[email-masked]>
Date: Wed, 31 Aug 2016 17:55:29 +0300

> On 31 Aug 2016, at 12:21 AM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

No they don’t always look at the 16-bit field (although they might), but they look at you funny when you tell them that 1.0 > 3.0 and that you should totally disable 3.0 and prefer to use 1.2 instead.

---

From: Brian Sniffen <[email-masked]>
Date: Wed, 31 Aug 2016 13:23:23 -0400

> may have risk for unfortunate confusions with SSLv2 and SSLv3.

That is wise.

What discussions were deferred as "this is just 1.3, wait for 2.0" that
will legitimately come back out of the woodwork if this is renamed to
TLS X, X > 1.9?

-Brian

---

From: Andrei Popov <[email-masked]>
Date: Wed, 31 Aug 2016 17:28:31 +0000

> No they don’t always look at the 16-bit field (although they might), but they look at you funny when you tell them that 1.0 > 3.0 and that you should totally disable 3.0 and prefer to use 1.2 inste…
:) True, but when this happens, I simply tell them that all SSL versions are broken, so they have to use TLS.
I'd rather have a consistent versioning story for TLS (1.0->1.1->1.2->2.0), rather than trying to fix the SSL3->TLS1.0 inconsistency at this point.
It's already fun enough to explain why DTLS jumped from 1.0 to 1.2 (or Windows from 8 to 10, for that matter).

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Wednesday, August 31, 2016 7:55 AM
To: Daniel Kahn Gillmor <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] TLS 1.3 -> TLS 2.0?

>> 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?

---

From: Yoav Nir <[email-masked]>
Date: Wed, 31 Aug 2016 20:34:28 +0300

> On 31 Aug 2016, at 8:28 PM, Andrei Popov <[email-masked]> wrote:
> 

I once had to explain to a GUI designer why this piece of UI genius was not a good idea

    Choose the minimal support SSL / TLS version:
         |       |
         +-------+
          | 1.0 |
          | 1.1 |
          | 1.2 |
          | 2.0 |
          | 3.0 |
          +-----+

---

From: Dave Garrett <[email-masked]>
Date: Wed, 31 Aug 2016 15:16:57 -0400

(replies to 4 separate but related posts, below)

> version of the 1.x line for people who need, well, an LTS version of the

You can't really do that. The HTTP/2 spec explicitly refers to TLS 1.3 and up as not needing the security restrictions on TLS 1.2 it lays out. Any TLS 1.2 LTS will need to be 1.2.x to deal with old documents citing the draft. (there's also citations of analysis of TLS 1.3 that reference it)

>   Value | Description | Reference

I've already dropped the struct major/minor labels and changed the type to just uint8x2 in my draft of this proposal. Explicitly adding a registry to go with this sounds good to me.

On Wednesday, August 31, 2016 05:35:47 am Xiaoyin Liu wrote:
> 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.[...]

"Normal" people have no clue what SSL or TLS is. Personally, I say that anyone saying "SSL" should be interrupted by saying "SSL is dead, long live TLS". All of SSL has been diediedied, so it's a reasonable cutoff point to support expectations for the moment, at least. SSL/TLS is a mess of over 20 years of stuff; we can't clean it up fully, but we can try to make it a little more clear. ;)

> if the WG really wants a TLSvX.0 name, the X really should be bigger than 3

We can call it TLS-2016 in addition to 2.0, which could help with some people, but doing the disjoint versioning thing is not a good idea, IMO (and a fair portion of the WG seems to be notably against it). I don't want to do a confusing thing to try to mitigate another confusing thing.

Dave

---

From: Bill Frantz <[email-masked]>
Date: Wed, 31 Aug 2016 12:24:30 -0700

We could call it TLS 3.4 which would match the internal ID. :-)

BTW, I think using something other than 1.3 is a good idea.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | When it comes to the world     | Periwinkle
(408)356-8506      | around us, is there any choice | 16345 Englewood Ave
www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032

---

From: Nick Sullivan <[email-masked]>
Date: Wed, 31 Aug 2016 22:35:13 +0000

I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I see a
few immediate issues with the proposal:
- it causes confusion with SSL 2.0
- it implies wire incompatibility with TLS 1.2
- it suggests there will be a forthcoming TLS 2.1 with only minor changes

If we're dead set on bumping the major version for a mostly backwards
compatible protocol change, we should just drop the minor version and go
with TLS/2.

Nick

---

From: Erik Nygren <[email-masked]>
Date: Wed, 31 Aug 2016 18:42:28 -0400

Is it worth having a poll (hate it, neutral, love it) on options to judge
preference
It seems like options are (I may have missed some):

- TLS 1.3  (ie, the default if we do nothing)
- TLS 2.0
- TLS 2
- TLS/2
- TLS 4.0
- TLS/4
- TLS 4
- TLS 34

On the topic of "what does this re-open", I'm not convinced it does.
The concept of doing a rename shortly before the last call goes way back
and has been correctly deferred as bike-shedding until now.
What color do we want our bike shed?

      Erik

---

From: Dave Garrett <[email-masked]>
Date: Wed, 31 Aug 2016 18:43:20 -0400

On Wednesday, August 31, 2016 06:35:13 pm Nick Sullivan wrote:
> I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0.

I was too, until we created a new cipher suite negotiation incompatible with previous versions.

> I see a few immediate issues with the proposal:

I disagree. There is a perpetual confusion between SSL and TLS, but this doesn't really make it that much worse.

> - it implies wire incompatibility with TLS 1.2

SSL 3.0 and TLS 1.0 share compatible hellos. A TLS 2 only client won't be able to connect to a TLS 1.2 only server, but that's true with all version changes. I don't see how a major version bump implies any more wire incompatibility, especially when we bend over backwards to maintain hello compatibility with SSL 3.

> - it suggests there will be a forthcoming TLS 2.1 with only minor changes

There could be, if we wanted to. I don't see a problem with that.

> compatible protocol change, we should just drop the minor version and go

I don't have a problem with dropping the ".0", but I don't see the point in the HTTP/2 style slash. TLS 2 is fine.

Dave

---

From: Richard Barnes <[email-masked]>
Date: Wed, 31 Aug 2016 19:05:46 -0400

I am in total agreement with Nick here.  "TLS 1.3" accurately describes
what we're doing here, and it's consistent with our past naming scheme.

There is no upside to changing away from 1.3, and as Nick notes, lots of
potential downside.

--Richard

On Wednesday, August 31, 2016, Nick Sullivan <[email-masked]>
wrote:

> On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Dave Garrett <[email-masked]>
Date: Wed, 31 Aug 2016 19:07:50 -0400

> What color do we want our bike shed?

A few of us have specifically had discussions with people about how "TLS 1.3 is really TLS 2.0"; just relabeling it that should be fine. We risk over-complicating things by doing a number jump a la Windows 10. I don't particularly want to have to answer the question "what happened to TLS 3?" for the next decade or so.

To repeat what I said in a previous reply, I think TLS 2-2016 or something is an ok way to reference things (outside of the spec doc).

Dave

---

From: Eric Mill <[email-masked]>
Date: Wed, 31 Aug 2016 22:01:43 -0400

>> compatible protocol change, we should just drop the minor version and go
FWIW, I've definitely seen real-world confusion about SSLv3 being a more
recent protocol than TLS 1.X, by organizations that should know better. If
there's interest and consensus, this could be a good opportunity to reset
the situation with TLS/2 or TLS 4.0.

I like TLS/2 aesthetically, and represents a similar level of
progress/reset that HTTP saw when it jumped from 1.1 to /2.

-- Eric

-- 
konklone.com | @konklone <https://twitter.com/konklone>

---

From: Judson Wilson <[email-masked]>
Date: Wed, 31 Aug 2016 23:05:25 -0700

> progress/reset that HTTP saw when it jumped from 1.1 to /2.

What is the slash in the name all about? Is it simply playing off the HTTP
start line specification? Does it have any relevance to TLS?