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 >

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?

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

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

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

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

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

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

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

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

[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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

[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

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

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

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

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