[TLS] Terminology clarification around SSL & TLS

Hi all, Following a recent discussion about how to name the successor of TLS 1.2, I wish to share an idea about a possible terminology clarification. I believe it could help to conciliate people understanding of SSL & TLS. We would have 3 notions: 1/ the technology, 2/ the protocols, 3/ the pr

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

Hi all, 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

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

Julien ÉLIE 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",

Re: [TLS] [Cfrg] 3DES diediedie

David McGrew (mcgrew) writes: >That’s great, facts leaven a debate. Yeah, but they also make it really boring, sigh. *Opinions*, now those are fun... Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

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

> From: Hubert Kario [mailto:hka...@redhat.com] > Sent: Wednesday, August 31, 2016 4:48 AM > To: Xiaoyin Liu > 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-bou

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

On Wednesday, 31 August 2016 09:35:47 CEST Xiaoyin Liu wrote: > > From: Hubert Kario [mailto:hka...@redhat.com] > > Sent: Wednesday, August 31, 2016 4:48 AM > > To: Xiaoyin Liu > > Cc: tls@ietf.org > > Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? > > > > On Tuesday, 30 August 2016 22:20:45 CEST Xiaoyin

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

On Tue 2016-08-30 16:14:06 -0400, 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 explaini

Re: [TLS] [Cfrg] 3DES diediedie

"Steven M. Bellovin" writes: > Yes. To a large extent, the "IoT devices are too puny for real > crypto" is a hangover from several years ago. It was once true; for > the most part, it isn't today, but people haven't flushed their cache > from the old received wisdom. This is certainly true for

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

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

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

> On 31 Aug 2016, at 12:21 AM, Daniel Kahn Gillmor > wrote: > > On Tue 2016-08-30 16:14:06 -0400, 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

Re: [TLS] RFC5746: Renegotiation Indication for minimal servers

On 26 August 2016 at 06:43, Sean Turner wrote: > Any more thoughts on these? I have no problem with implementations that don't use R-I (in either extension or SCSV form) if they don't intend to ever renegotiate. I know that that disagrees with RFC 5746, but there you have it. __

Re: [TLS] [Cfrg] Document on increasing the lifetime of session keys

Hello, Eric and Mihir! One other consideration about the connection between key meshing and usage of KDFs (with session keys derived from a master key in the moment of “Key update”): they can (and in a lot of cases they should) be used together, if you have really strict limitations on key life

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

+10k Rich Salz responded: > DKG proposed: >> 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 >>--+---

Re: [TLS] RFC5746: Renegotiation Indication for minimal servers

Recall that the original renegotiation attack relied on a client that has no intention to renegotiate but was still fooled into renegotiating the attackers’s connection to the server. To prevent this attack, it is essential that the client includes an empty R-I in its client hello. This negative

Re: [TLS] [Cfrg] 3DES diediedie

> From: Derek Atkins > Date: Wed, 31 Aug 2016 10:17:25 -0400 > "Steven M. Bellovin" writes: > > Yes. To a large extent, the "IoT devices are too puny for real > > crypto" is a hangover from several years ago. It was once true; for > > the most part, it isn't today, but people haven't flu

Re: [TLS] Issue 588: Code point assignment for ticket_early_data_info

On 08/30/2016 06:50 PM, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/588 >

Re: [TLS] [Cfrg] 3DES diediedie

Hilarie Orman writes: >> From: Derek Atkins >> Date: Wed, 31 Aug 2016 10:17:25 -0400 > >> "Steven M. Bellovin" writes: > >> > Yes. To a large extent, the "IoT devices are too puny for real >> > crypto" is a hangover from several years ago. It was once true; for >> > the most part, it isn

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

Erik Nygren writes: > 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 c

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

> 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. :) True, but when this happens, I simply tell them that all SSL versions are broken, so t

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

> On 31 Aug 2016, at 8:28 PM, Andrei Popov 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. > :) True, but when this happens

Re: [TLS] Terminology clarification around SSL & TLS

On Wed 2016-08-31 03:35:38 -0400, Julien ÉLIE wrote: > Following a recent discussion about how to name the successor of TLS > 1.2, I wish to share an idea about a possible terminology clarification. > I believe it could help to conciliate people understanding of SSL & TLS. > > We would have 3 noti

Re: [TLS] Terminology clarification around SSL & TLS

> i would like to continue to be able to say unambiguously that all known > versions of SSL are badly broken and should be avoided. Let's not muddy > those waters further. +1 -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz __

Re: [TLS] Terminology clarification around SSL & TLS

+1. Let's not use a proprietary protocol name for a standard protocol. Conveniently, all SSL is broken now, long live TLS! -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich Sent: Wednesday, August 31, 2016 10:40 AM To: Daniel Kahn Gillmor ; Julien ÉLIE ;

[TLS] 0-RTT encrypted data limits

Current draft has the following text in it: If any of these checks fail, the server MUST NOT respond with the extension and must discard all the remaining first flight data (thus falling back to 1-RTT). If the client attempts a 0-RTT handshake but the server rejects it, it will gen

Re: [TLS] 0-RTT encrypted data limits

On Wed, Aug 31, 2016 at 11:14 AM, Hubert Kario wrote: > Current draft has the following text in it: > > If any of these checks fail, the server MUST NOT respond > with the extension and must discard all the remaining first > flight data (thus falling back to 1-RTT). If the client atte

Re: [TLS] 0-RTT encrypted data limits

On Wed, Aug 31, 2016 at 08:14:33PM +0200, Hubert Kario wrote: > Current draft has the following text in it: > > If any of these checks fail, the server MUST NOT respond > with the extension and must discard all the remaining first > flight data (thus falling back to 1-RTT). If the clie

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

(replies to 4 separate but related posts, below) On Wednesday, August 31, 2016 03:52:44 am Peter Gutmann wrote: > Julien ÉLIE 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

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

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

Re: [TLS] Terminology clarification around SSL & TLS

On Wednesday, August 31, 2016 12:44:02 pm Daniel Kahn Gillmor wrote: > i would like to continue to be able to say unambiguously that all known > versions of SSL are badly broken and should be avoided. Let's not muddy > those waters further. +1 ___ TLS

Re: [TLS] [Cfrg] 3DES diediedie

> From: Brian Sniffen > >> From: Derek Atkins > >> Date: Wed, 31 Aug 2016 10:17:25 -0400 > > > >> "Steven M. Bellovin" writes: > > > >> > Yes. To a large extent, the "IoT devices are too puny for real > >> > crypto" is a hangover from several years ago. It was once true; for > >>

Re: [TLS] [Cfrg] 3DES diediedie

On Wed, August 31, 2016 3:48 pm, Hilarie Orman wrote: > > An ARM is far too much hardware to throw at "read sensor/munge data/send > data". What about an 8051? > Hilarie -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer

Re: [TLS] TLS 1.3 -> TLS 2.0

I've updated my WIP based on feedback and submitted it as a PR here: https://github.com/tlswg/tls13-spec/pull/612 If anyone else catches another spot that needs some updating, please comment on the PR. As this is a rather notable change, I do propose this remain open for discussion for at least

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

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

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

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 con

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

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: > - it causes confus

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

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 wro

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

On Wednesday, August 31, 2016 06:42:28 pm Erik Nygren wrote: > 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

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

On Wed, Aug 31, 2016 at 7:05 PM, Richard Barnes wrote: > 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 downs

Re: [TLS] [Cfrg] 3DES diediedie

On 31 Aug 2016, at 10:17, Derek Atkins wrote: > "Steven M. Bellovin" writes: > >> Yes. To a large extent, the "IoT devices are too puny for real >> crypto" is a hangover from several years ago. It was once true; for >> the most part, it isn't today, but people haven't flushed their cache >> from

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

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