[TLS] Terminology clarification around SSL & TLS

[Julien ÉLIE]

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

The technology is SSL, and is sometimes also refered to as SSL/TLS.  
(Note that bare TLS is not a technology.)


The protocols are:
- deprecated eponym SSL,
- TLS,
- DTLS.

The protocol versions are:
- 1.0, 2.0 and 3.0 for SSL,
- 1.0, 1.1, 1.2 and 2.0 for TLS,
- 1.0, 1.2 and 2.0 for DTLS.



Any comments about that proposal?

--
Julien ÉLIE

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

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

[Julien ÉLIE]

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 something in the 1.x family, and it's quite misleading calling it 
1.3.


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

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

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

[Peter Gutmann]

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", 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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Peter Gutmann]

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?

[Hubert Kario]

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

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

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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Xiaoyin Liu]

> 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-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.
> 
> well, that's not the experience of our support engineers, people still confuse
> SSLv3 with TLSv

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hubert Kario]

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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Daniel Kahn Gillmor]

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

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 


Then you could tell people to just look it up in the table.

--dkg, tongue only marginally in cheek


signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Derek Atkins]

"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 AES, mostly because many small chips are
including AES accelerators in hardware.  It's not quite true for public
key solutions; there are still very small devices where even ECC takes
too long (and yes, there are cases where 200-400ms is still too long).

> It pays to look again at David Wagner's slides from 2005, on sensor
> nets and crypto:
> https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
>
>
> --Steve Bellovin, https://www.cs.columbia.edu/~smb

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

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

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

[Salz, Rich]

> 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 

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

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz


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

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

[Yoav Nir]

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

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.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

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.

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

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 lifetime. In these cases KDF may be used 
for deriving keys for the message (or packet or some other block of data that 
is to be handled separately) and key meshing to make it possible to handle 
rather long messages.
For example, if you have to limit key usage with 4 KB (e.g. your potential 
adversary has truly powerful capabilities of intercepting side-channel leakage 
of a key on operations with it) and you handle messages of variable length, you 
can KDF a new session key for each message and then work as usual – knowing 
that when the length of a message exceeds 4 KB, key meshing will work and you 
would be able to continue working. And it’ll be done transparently – just like 
you are using a modified block cipher mode, which expands key lifetime.
Otherwise you’ll have either to limit the size of messages (which is not always 
suitable), or get several KDFed session keys from the master key for a message 
if it’s long enough – which means hard fragmentation of messages and additional 
costs for starting/stopping encryption thread.
 --  Regards,
Evgeny Alekseev
CryptoPro


>Воскресенье, 28 августа 2016, 17:42 +03:00 от "Stanislav V. Smyshlyaev" 
>:
>
>‎Dear Eric,
>
>Thank you for your comment - indeed, re-keying mechanisms based on secret 
>state are widely used in the protocols (key trees are usual practice in ESP 
>with GOSTs for more than 10 years, for example). My point is that a simple 
>(e.g. without any additional keys or structures) and effective mechanism to 
>increase ‎block cipher modes limitations on plaintext size can be helpful 
>itself, without incorporating to a protocol. 
>
>About connection with TLS 1.3 draft - for example, we don't want the GCM mode 
>be defined inside some protocol RFC, it should be defined separately, isn't 
>it?  So the question is that if such mechanisms are needed, than separate 
>documents on them can be a better solution.
>
>And my primary point here is about stateless techniques: as follows from t‎he 
>preprint I cited before, the key lifetime for CTR can be increased 
>quadratically, for example. 
>
>Kindest regards,
>Stanislav
>
>От:  Eric Rescorla
>Отправлено:  воскресенье, 28 августа 2016 г., 16:52
>Кому:  Stanislav V. Smyshlyaev
>Копия:  c...@irtf.org; Mihir Bellare; Paul Lambert; Paterson, Kenny; Mike 
>Hamburg; < tls@ietf.org >
>Тема:  Re: [TLS] Document on increasing the lifetime of session keys
>
>Stanislav,
>
>TLS 1.3 incorporates a rekeying mechanism (KeyUpdate) similar to that if 
>Abdalla and Bellare 1(b).
>
>-Ekr
>
>
>On Sun, Aug 28, 2016 at 3:48 AM, Stanislav V. Smyshlyaev  < smys...@gmail.com 
>> wrote:
>>Dear colleagues,
>>Since there is a considerable interest to the question of increasing session 
>>keys lifetime (several productive off-the-list personal discussions about 
>>CryptoPro key meshing algorithms and  http://eprint.iacr.org/2016/628  
>>started after the Friday posting), maybe we should think about getting 
>>started a work on a document on efficient re-keying (about techniques without 
>>secret state and/or techniques with it (like in M. Abdalla and M. Bellare 
>>work,  https://cseweb.ucsd.edu/~mihir/papers/rekey.html )) mechanisms for 
>>common cipher modes (CTR, CCM, GCM, CBC, CFB) in CFRG? 
>>If you consider it reasonable, we can prepare a first version of such a draft 
>>based on our results (both included in that our preprint and new ones which 
>>we are working on currently) before IETF 97 to be able to have a discussion 
>>on this issue there in Seoul.
>>Kindest regards,
>>Stanislav Smyshlyaev
>>___
>>TLS mailing list
>>TLS@ietf.org
>>https://www.ietf.org/mailman/listinfo/tls
>>
>
>
>___
>Cfrg mailing list
>c...@irtf.org
>https://www.irtf.org/mailman/listinfo/cfrg

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

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

[=JeffH]

+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
>>--+-+--
>> 0x30 |SSLv3| RFC 6101, RFC 7568
>> 0x31 |   TLSv1.0   | RFC 2246
>> 0x32 |   TLSv1.1   | RFC 4346
>> 0x33 |   TLSv1.2   | RFC 5246
>> 0x34 |TLSv4| RFC 
>
> YES.  Do this no matter what the last Description value ends up being.



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

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

[Karthikeyan Bhargavan]

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 acknowledgment is as useful as a positive one.

This is particularly true on the client side. A server that does not support 
renegotiation
may be able to get away with not supporting R-I, but this probably also leads 
to 
some (weak) attacks.


> On 31 Aug 2016, at 11:21, Martin Thomson  wrote:
> 
> 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.
> 
> ___
> 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] [Cfrg] 3DES diediedie

[Hilarie Orman]

>  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 flushed their cache
>  > from the old received wisdom.

>  This is certainly true for AES, mostly because many small chips are
>  including AES accelerators in hardware.  It's not quite true for public
>  key solutions; there are still very small devices where even ECC takes
>  too long (and yes, there are cases where 200-400ms is still too long).

>  > It pays to look again at David Wagner's slides from 2005, on sensor
>  > nets and crypto:
>  > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
>  >

Unattended sensors with wifi present an unsolved crypto problem.  They
can last 10 years on an AA battery without crypto, probably well less
than a year if they have to do any kind of encryption.  These things
will be everywhere, providing the data that will underly all kinds of
decision-making.

Although much of the solution may lie in hardware innovation, the
world really does need minimal crypto algorithms.

Hilarie



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

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

[Benjamin Kaduk]

On 08/30/2016 06:50 PM, Eric Rescorla wrote:
> 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
> 
>

It seems to make more sense to keep them in separate numberspaces, to me.

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

Re: [TLS] [Cfrg] 3DES diediedie

[Brian Sniffen]

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't today, but people haven't flushed their cache
>>  > from the old received wisdom.
>
>>  This is certainly true for AES, mostly because many small chips are
>>  including AES accelerators in hardware.  It's not quite true for public
>>  key solutions; there are still very small devices where even ECC takes
>>  too long (and yes, there are cases where 200-400ms is still too long).
>
>>  > It pays to look again at David Wagner's slides from 2005, on sensor
>>  > nets and crypto:
>>  > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
>>  >
>
> Unattended sensors with wifi present an unsolved crypto problem.  They
> can last 10 years on an AA battery without crypto, probably well less
> than a year if they have to do any kind of encryption.  These things
> will be everywhere, providing the data that will underly all kinds of
> decision-making.

Assuming there are *some* integrity requirements for the data, and that
they are deploying 32-bit ARM with AES support (stipulating that ~every
CPU will have AES support in a few years, as ~every CPU sold does
today), we're talking about *either* an ECDHE negotiation every few
months or a pre-shared key, good for ten years.

AES-GCM with hardware support compares favorably to SHA-2 without
hardware support, so if they've been able to last 10 years before, they
should do just fine in the future.  The old devices won't last forever,
and probably can't run TLS 1.3---that's fine, TLS 1.2 will be with us
for ten years after 1.3 is out.

-Brian

> Although much of the solution may lie in hardware innovation, the
> world really does need minimal crypto algorithms.
>
> Hilarie
>
>
>
> ___
> 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?

[Brian Sniffen]

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

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

> 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

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

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

[Andrei Popov]

> 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 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:tls-boun...@ietf.org] On Behalf Of Yoav Nir
Sent: Wednesday, August 31, 2016 7:55 AM
To: Daniel Kahn Gillmor 
Cc:  
Subject: 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 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
> 
> 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?

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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

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

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

 

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

Re: [TLS] Terminology clarification around SSL & TLS

[Daniel Kahn Gillmor]

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 notions:
> 1/ the technology,
> 2/ the protocols,
> 3/ the protocol versions.
>
> The technology is SSL, and is sometimes also refered to as SSL/TLS.  
> (Note that bare TLS is not a technology.)

please no.  the technology is TLS.  The time for us to have made the
other decision was 17 years ago before TLS 1.0 was formalized.

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.

 --dkg

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

Re: [TLS] Terminology clarification around SSL & TLS

[Salz, Rich]

> 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



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

Re: [TLS] Terminology clarification around SSL & TLS

[Andrei Popov]

+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@ietf.org
Subject: 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



___
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] 0-RTT encrypted data limits

[Hubert Kario]

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 generally
not have the 0-RTT record protection keys and must instead
trial decrypt each record with the 1-RTT handshake keys
until it finds one that decrypts properly, and then pick up
the handshake from that point.

My understanding of that, in case client does 0-RTT but server rejects it 
(because the PSK is too old or its time is different enough) is that the 
server needs to keep on reading arbitrarily large amounts of data it has no 
idea what to do with. All using slow path (thinking exception handling in 
particular).

Is my understanding correct?

Why is there no limit on the amount of data that can be encrypted using PSK 
keys (0-RTT)?
-- 
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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT encrypted data limits

[Eric Rescorla]

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 attempts
> a 0-RTT handshake but the server rejects it, it will generally
> not have the 0-RTT record protection keys and must instead
> trial decrypt each record with the 1-RTT handshake keys
> until it finds one that decrypts properly, and then pick up
> the handshake from that point.
>
> My understanding of that, in case client does 0-RTT but server rejects it
> (because the PSK is too old or its time is different enough) is that the
> server needs to keep on reading arbitrarily large amounts of data it has no
> idea what to do with. All using slow path (thinking exception handling in
> particular).
>
> Is my understanding correct?
>

It's not clear to me that it's particularly slow. You get a MAC failure and
rejecting
the packet is slightly faster than processing it.


Why is there no limit on the amount of data that can be encrypted using PSK
> keys (0-RTT)?
>

I don't think this would usefully improve things.

-Ekr

--
> 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
> ___
> 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] 0-RTT encrypted data limits

[Ilari Liusvaara]

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 client attempts
> a 0-RTT handshake but the server rejects it, it will generally
> not have the 0-RTT record protection keys and must instead
> trial decrypt each record with the 1-RTT handshake keys
> until it finds one that decrypts properly, and then pick up
> the handshake from that point.
> 
> My understanding of that, in case client does 0-RTT but server rejects it 
> (because the PSK is too old or its time is different enough) is that the 
> server needs to keep on reading arbitrarily large amounts of data it has no 
> idea what to do with. All using slow path (thinking exception handling in 
> particular).

Yes, read the data and attempt to decrypt it with handshake keys (with
GCM and POLY1305, failed decryptions are faster than successful ones,
of course there is exception overhead if those are used).


-Ilari

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

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

[Dave Garrett]

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

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)


On Tuesday, August 30, 2016 05:21:21 pm Daniel Kahn Gillmor wrote:
> 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 

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


On Wednesday, August 31, 2016 04:47:59 am Hubert Kario wrote:
> 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

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

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

[Bill Frantz]

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

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

Re: [TLS] Terminology clarification around SSL & TLS

[Dave Garrett]

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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Hilarie Orman]

>  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
>  >>  > the most part, it isn't today, but people haven't flushed their cache
>  >>  > from the old received wisdom.
>  >
>  >>  This is certainly true for AES, mostly because many small chips are
>  >>  including AES accelerators in hardware.  It's not quite true for public
>  >>  key solutions; there are still very small devices where even ECC takes
>  >>  too long (and yes, there are cases where 200-400ms is still too long).
>  >
>  >>  > It pays to look again at David Wagner's slides from 2005, on sensor
>  >>  > nets and crypto:
>  >>  > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
>  >>  >
>  >
>  > Unattended sensors with wifi present an unsolved crypto problem.  They
>  > can last 10 years on an AA battery without crypto, probably well less
>  > than a year if they have to do any kind of encryption.  These things
>  > will be everywhere, providing the data that will underly all kinds of
>  > decision-making.

>  Assuming there are *some* integrity requirements for the data, and that
>  they are deploying 32-bit ARM with AES support (stipulating that ~every
>  CPU will have AES support in a few years, as ~every CPU sold does
>  today), we're talking about *either* an ECDHE negotiation every few
>  months or a pre-shared key, good for ten years.

>  AES-GCM with hardware support compares favorably to SHA-2 without
>  hardware support, so if they've been able to last 10 years before, they
>  should do just fine in the future.  The old devices won't last forever,
>  and probably can't run TLS 1.3---that's fine, TLS 1.2 will be with us
>  for ten years after 1.3 is out.

>  -Brian

>  > Although much of the solution may lie in hardware innovation, the
>  > world really does need minimal crypto algorithms.
>  >
>  > Hilarie
>  >

An ARM is far too much hardware to throw at "read sensor/munge data/send data".

Hilarie

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

Re: [TLS] [Cfrg] 3DES diediedie

[Derek Atkins]

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 and Internet Security Consultant

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

Re: [TLS] TLS 1.3 -> TLS 2.0

[Dave Garrett]

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 a week or so before the chair assesses consensus.


Dave

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

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

[Nick Sullivan]

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

On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz  wrote:

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

[Erik Nygren]

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



On Wed, Aug 31, 2016 at 6:35 PM, Nick Sullivan 
wrote:

> 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
>
> On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz 
> wrote:
>
>> 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
>>
>> ___
>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dave Garrett]

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 confusion with SSL 2.0

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.

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

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

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

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

[Richard Barnes]

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

> 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
>
> On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz  > wrote:
>
>> 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
>>
>> ___
>> 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 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
> - 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?

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

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

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

[Eric Mill]

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 downside.
>
> --Richard
>
> On Wednesday, August 31, 2016, Nick Sullivan 
> wrote:
>
>> 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
>>
>
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



>
>> On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz 
>> wrote:
>>
>>> 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
>>>
>>> ___
>>> 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
>
>


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

Re: [TLS] [Cfrg] 3DES diediedie

[Steven M. Bellovin]

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 the old received wisdom.
>
> This is certainly true for AES, mostly because many small chips are
> including AES accelerators in hardware.  It's not quite true for public
> key solutions; there are still very small devices where even ECC takes
> too long (and yes, there are cases where 200-400ms is still too long).
>
Certainly plausible.  What I'm saying is (a) don't assert, measure; and
(b) measure again next year because tech keeps improving.

As for your specific points: if AES is indeed feasible, we don't need
new ciphers.  If elliptic curve is too slow, the only answer is architectures
that don't use public key at all; we're not going to find new, cheaper
public key algorithms without a *lot* of effort and the people who can
do that sort of thing are too busy working on post-quantum crypto.

The remaining approach is a cheaper protocol than TLS.  That shouldn't
be hard at all, especially if we're going back to KDCs.


--Steve Bellovin, https://www.cs.columbia.edu/~smb


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

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

[Judson Wilson]

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

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?


On Wed, Aug 31, 2016 at 7:01 PM, Eric Mill  wrote:

>
>
> 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 downside.
>>
>> --Richard
>>
>> On Wednesday, August 31, 2016, Nick Sullivan 
>> wrote:
>>
>>> 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
>>>
>>
> 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
>
>
>
>>
>>> On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz 
>>> wrote:
>>>
 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

 ___
 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
>>
>>
>
>
> --
> konklone.com | @konklone 
>
> ___
> 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