[TLS] Issue 588: Code point assignment for ticket_early_data_info

[Eric Rescorla]

https://github.com/tlswg/tls13-spec/issues/588

I neglected to assign a code point for this in draft-15. I note, however,
that
we currently have it occupying a different code point space than hello
extensions.
I am sort of wondering if it would be more useful for them to be in the same
space. Probably not, but I thought I would ask before assigning 1, which is
the natural code point otherwise.

https://tlswg.github.io/tls13-spec/#rfc.section.4.5.1

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Xiaoyin Liu]

> -Original Message-
> From: TLS [mailto:tls-boun...@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. 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Rob Stradling]

On 30/08/16 21:14, Hubert Kario wrote:

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

it's silly at this point


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:


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.


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

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

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

[Erik Nygren]

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"  wrote:

> On Tuesday, August 30, 2016 02:36:51 pm Xiaoyin Liu wrote:
> > 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
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dave Garrett]

On Tuesday, August 30, 2016 02:36:51 pm Xiaoyin Liu wrote:
> 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

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

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

[Xiaoyin Liu]

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



Best,

Xiaoyin

From: Dave Garrett
Sent: Tuesday, August 30, 2016 2:19 PM
To: tls@ietf.org
Subject: [TLS] TLS 1.3 -> TLS 2.0?



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

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

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

[Andrei Popov]

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:tls-boun...@ietf.org] On Behalf Of Dave Garrett
Sent: Tuesday, August 30, 2016 11:20 AM
To: tls@ietf.org
Subject: [TLS] TLS 1.3 -> TLS 2.0?

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

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

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

[TLS] TLS 1.3 -> TLS 2.0?

[Dave Garrett]

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

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

Re: [TLS] [Cfrg] 3DES diediedie

[David McGrew (mcgrew)]

Hi Peter,



On 8/30/16, 5:41 AM, "Peter Gutmann"  wrote:

>David McGrew (mcgrew)  writes:
>
>>See for instance slides 8 and 9 of Daniel Shumow's talk at NIST’s LWC
>>workshop last year:
>>http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.pdf
>
>So looking at slide 6 from that, the first four systems he lists are desktop
>PCs (in all but form factor), it's only the last two that are down at the
>resource levels of IoT.  I'm not sure why he picked the Arduinos there because
>I wouldn't really consider them terribly representative of IoT devices, was it
>to get something that people are familiar with?  Even if you're wanting to
>restrict yourself to well-known complete systems I think at least an ESP8266
>(80Mhz SoC with 96K RAM, 64K flash, no multiply or divide by default) should
>get a mention.
>
>Slide 9 is even further removed from IoT practicality, that stuff may be fine
>on the PC-equivalents but won't work on real IoT gear.
>
>I'm currently working with some embedded systems guys to come up with a list
>of requirements for IoT crypto (as with the TLS-LTS stuff, various IP/legal
>issues means many contributors don't want to say anything in public), I'll
>post it to the list when we've finished arguing :-).
>
>Peter.

That’s great, facts leaven a debate.

thanks

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

Re: [TLS] [Cfrg] 3DES diediedie

[Peter Gutmann]

Jon Callas  writes:

>Current cryptographic standards work for IoT

That's only if you use the circular argument that IoT is defined to be
whatever can run DTLS (or whatever you take as "current cryptographic
standards", the slides mention DTLS).  An yeah, I can then define my IoT to be
"whatever can't run DTLS" :-).  Stand by for a requirements list coming from a
bunch of IoT/embedded people...

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

Re: [TLS] [Cfrg] 3DES diediedie

[Peter Gutmann]

David McGrew (mcgrew)  writes:

>See for instance slides 8 and 9 of Daniel Shumow's talk at NIST’s LWC
>workshop last year:
>http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.pdf

So looking at slide 6 from that, the first four systems he lists are desktop
PCs (in all but form factor), it's only the last two that are down at the
resource levels of IoT.  I'm not sure why he picked the Arduinos there because
I wouldn't really consider them terribly representative of IoT devices, was it
to get something that people are familiar with?  Even if you're wanting to
restrict yourself to well-known complete systems I think at least an ESP8266
(80Mhz SoC with 96K RAM, 64K flash, no multiply or divide by default) should
get a mention.

Slide 9 is even further removed from IoT practicality, that stuff may be fine
on the PC-equivalents but won't work on real IoT gear.

I'm currently working with some embedded systems guys to come up with a list
of requirements for IoT crypto (as with the TLS-LTS stuff, various IP/legal
issues means many contributors don't want to say anything in public), I'll
post it to the list when we've finished arguing :-).

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