Subject: [ietf-tls] On doing TLS 1.1

From: Win Treese <[email-masked]>
Date: Wed, 30 May 2001 09:40:52 -0400

There has been a small bit of discussion recently about a "1.1"
specification for TLS.

I'd like to see a bit more discussion about this, particularly about
to whether or not this working group needs to do that work. The
charter is (and always has been) focused mainly on defining a standard
for TLS and advancing it on the standards track. I certainly
appreciate the desire for adding newer and innovative work, and I'm
please to see such thinking. But before undertaking the larger
project, I'd like to get a better sense from the working group about
whether or not it makes sense to do.

Comments?

Win Treese
Chair, TLS working group
[email-masked]

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: [email-masked]
Date: Wed, 30 May 2001 11:35:15 -0400

Has anyone considered adding compression to TLS?
Should be easy and would save a lot bandwidth for wireless apps at no
cost in CPU (MIPs spent compressing would offset MIPs which would have
been spent on crypto).

     Doug Dillon

Win Treese <[email-masked]>@lists.certicom.com on 05/30/2001 09:40:52 AM

Please respond to "IETF Transport Layer Security WG"
      <[email-masked]>

                                                              
 Sent by: [email-masked]          
                                                              
 To:      "IETF Transport Layer Security WG"                  
          <[email-masked]>                       
                                                              
 cc:      (bcc: Doug Dillon/HNS)                              

 Subject: [ietf-tls] On doing TLS 1.1                         

Comments?

Win Treese
Chair, TLS working group
[email-masked]

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

---

From: "Joseph Hui" <[email-masked]>
Date: Wed, 30 May 2001 10:15:37 -0700

My take is it makes sense to do an appropriately scoped 1.1.
Let's keep it light, to ensure its timely roll-out.  

As we are committing ourselves to do 1.1, then it also
makes sense to set a schedule for 1.2.  Otherwise, nobody
wants to get left behind, fearing the uncertainty of 1.2
(or whatever the next version that may never come), which
will result in 1.1 being laden with so many goodies that 
it just can't take off.

So allow me to reiterate my previous suggestion that we
plot a TLS roadmap, i.e. what will be in 1.1 and what next.  
I believe Simon & company are finalizing their TLS extensions
draft, which encompasses several reasonably mature proposals.  
It should give us a good starting point to scope out 1.1.
 
Regards,

Joe Hui
Research Engineer
Digital Island
================================================================

-----Original Message-----
From: Win Treese [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 6:41 AM
To: IETF Transport Layer Security WG
Subject: [ietf-tls] On doing TLS 1.1

Comments?

Win Treese
Chair, TLS working group
[email-masked]

---

---

From: "Andreas Sterbenz" <[email-masked]>
Date: Wed, 30 May 2001 23:02:33 +0200

Given the way TLS achieves backwards compatibility - namely by implementing
all desired protocol versions - I am very much in favor of keeping the
number of versions to a minimum. As all the features people really seem to
be interested in (name based virtual hosting, applicability to low bandwidth
devices, additional ciphersuites) can be achieved without requiring changes
to the TLS 1.0 spec itself, I see no reason to rush TLS 1.1.

I would suggest that this working group takes on TLS 1.1 and fixes the
(arguably) theoretical cryptographic weaknesses in the protocol and improves
protocol efficiency. My list of topics would include the Bodo Möller
handshake attack, MACing before encrypting (insecure according to Krawczyk),
the PRF function, and record protocol overhead among other things.

 Andreas Sterbenz              mailto:[email-masked]

----- Original Message -----
From: "Joseph Hui" <[email-masked]>
To: "IETF Transport Layer Security WG" <[email-masked]>
Sent: Wednesday, May 30, 2001 7:15 PM
Subject: [ietf-tls] RE: On doing TLS 1.1

Regards,

Joe Hui
Research Engineer
Digital Island

---

---

From: "Joseph Hui" <[email-masked]>
Date: Wed, 30 May 2001 15:07:59 -0700

If we reserve 1.1 for the grandiose, then there arises the need for 1.0
plus
or 1.0.whatever to cram in the urgently needed features, such as the
dns_name
extension.  However, I recall sound arguments were made in the past that
if
we don't increment the version number (for instituting such features),
then
web servers and browsers that are now TLS 1.0 compatible will suddenly
become
TLS 1.0 incompatible and their vendors/custodians will thus squawk,
rightfully
so, because of the confusion.

Joe
==========================================

-----Original Message-----
From: Andreas Sterbenz [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 2:03 PM
To: IETF Transport Layer Security WG
Subject: [ietf-tls] RE: On doing TLS 1.1

Given the way TLS achieves backwards compatibility - namely by
implementing
all desired protocol versions - I am very much in favor of keeping the
number of versions to a minimum. As all the features people really seem
to
be interested in (name based virtual hosting, applicability to low
bandwidth
devices, additional ciphersuites) can be achieved without requiring
changes
to the TLS 1.0 spec itself, I see no reason to rush TLS 1.1.

I would suggest that this working group takes on TLS 1.1 and fixes the
(arguably) theoretical cryptographic weaknesses in the protocol and
improves
protocol efficiency. My list of topics would include the Bodo Möller
handshake attack, MACing before encrypting (insecure according to
Krawczyk),
the PRF function, and record protocol overhead among other things.

----- Original Message -----
From: "Joseph Hui" <[email-masked]>
To: "IETF Transport Layer Security WG" <[email-masked]>
Sent: Wednesday, May 30, 2001 7:15 PM
Subject: [ietf-tls] RE: On doing TLS 1.1

Regards,

Joe Hui
Research Engineer
Digital Island

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: Eric Rescorla <[email-masked]>
Date: 30 May 2001 22:12:00 -0700

"Joseph Hui" <[email-masked]> writes:
> If we reserve 1.1 for the grandiose, then there arises the need for
> 1.0 plus or 1.0.whatever to cram in the urgently needed features,
> such as the dns_name extension.  However, I recall sound arguments
> were made in the past that if we don't increment the version number
> (for instituting such features), then web servers and browsers that
> are now TLS 1.0 compatible will suddenly become TLS 1.0 incompatible
> and their vendors/custodians will thus squawk, rightfully so,
> because of the confusion.
We can't make these features MUSTs for TLS 1.0, but the point
of extensions is that you can implement them or not as you choose.

It won't cause any problem to add these as optional extensions
to 1.0

-Ekr

---

---

From: Eric Rescorla <[email-masked]>
Date: 30 May 2001 22:13:01 -0700

> handshake attack, MACing before encrypting (insecure according to Krawczyk),
I'd like to hear an argument as to why MACing before encrypting is
a problem. It's relatively standard practice.

> the PRF function
What's wrong with the PRF function?

>and record protocol overhead
Computational or bandwidth overhead?

-Erk

---

---

From: "Andreas Sterbenz" <[email-masked]>
Date: Thu, 31 May 2001 10:26:37 +0200

> a problem. It's relatively standard practice.
That is based on a remark made by Hugo Krawczyk at his EuroCrypt 2001
presentation "Analysis of Key-Exchange Protocols and Their Use for Building
Secure Channels." I quickly glanced over the paper but could not find a
mention of the problem. I suppose this will be covered in his Crypto 2001
paper "The Order Of Encryption And Authentication For Protecting
Communications (Or: How Secure Is SSL?)." I have not read it but it sure
sounds relevant to us, at least as a theoretical weakness.

> What's wrong with the PRF function?
Some people on the list have argued that it is unneccessarily complex and I
tend to agree.

> Computational or bandwidth overhead?
Bandwidth. Computational would be nice, but I do not see a way to achieve
that.

---

---

From: [email-masked]
Date: Thu, 31 May 2001 10:08:16 -0500

I agree with Eric.  There is no need to increment the version number for TLS
in order to add the dns_name extension and the wireless extensions.  These
extensions are all backwards compatible.  It is possible to communicate
between a client that supports the extensions and a server that does not and
vice versa.  As they are all optional features no vendor's web server or
browser currently supporting TLS 1.0 will break as a result of them.

The latest I-D will be out soon from Simon Blake-Wilson and Magnus Nystrom
and it will present the technical details on how this is achieved.  I would
like to see these extensions in TLS 1.0.

-- maureen

Maureen Stillman
Nokia
Member of Scientific Staff             Voice: (607)273-0724 x62
Internet Commerce Enhancement  Fax: (607)275-3610
127 W. State Street                     Mobile: (607)227-2933
Ithaca, NY 14850
e-mail: [email-masked]
www.nokia.com

-----Original Message-----
From: ext Eric Rescorla [mailto:[email-masked]]
Sent: Thursday, May 31, 2001 1:12 AM
To: IETF Transport Layer Security WG
Subject: [ietf-tls] RE: On doing TLS 1.1

-Ekr

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: Eric Rescorla <[email-masked]>
Date: 31 May 2001 08:15:09 -0700

> Some people on the list have argued that it is unneccessarily complex and I
Unfortunately, the reason it's so complex is that it was provided to
us by Hugo's group and is therefore allegedly free of theoretical
weaknesses. :(

> Bandwidth. Computational would be nice, but I do not see a way to achieve
Neither do I. OTOH, The only way to save a significant amount of
bandwidth is MAC truncation.

-Ekr

---

---

From: "Andreas Sterbenz" <[email-masked]>
Date: Thu, 31 May 2001 17:43:18 +0200

> bandwidth is MAC truncation.

Yes and no. I see two places to save bandwidth in addition to MAC
truncation: (a) the record version number, which serves no particular
purpose except in the initial hello messages and (b) block cipher padding.
For AES average padding length is 8.5 bytes which could be reduces to 0 by
using counter mode or cipher text stealing mode.

Combined that is an average saving of 10.5 byte per record in case of a 128
bit block cipher, which is not too bad.

Please note that I will be out of the office for three weeks starting
tomorrow and may not be able discuss this further during that time.

---