Subject: [ietf-tls] RE: New AES ciphersuites draft

From: "Tord Persokrud (ETO)" <[email-masked]>
Date: Tue, 5 Dec 2000 09:23:47 +0100

Pete, concerning your point 2 below, i.e. always ensuring that two TLS implementations
supporting AES can interoperate. It would be good, from our point of view that even
our most restricted clients supporting TLS and AES could conform to this document.

It follows from this that it would be good to change the wording so that 

Servers MUST provide both TLS_RSA_WITH_AES_128_CBC_SHA and
         TLS_DHE_RSA_WITH_AES_128_CBC_SHA.

Clients MUST provide at least one of
         TLS_RSA_WITH_AES_128_CBC_SHA and
         TLS_DHE_RSA_WITH_AES_128_CBC_SHA.

In case the server has a policy to only use TLS_DHE and the client doesn't 
provide this, the server won't accept the connection.

Tord Persokrud
Ericsson

-----Original Message-----
From: Pete Chown [mailto:[email-masked]]
Sent: 15. november 2000 17:35
To: IETF Transport Layer Security WG
Subject: [ietf-tls] New AES ciphersuites draft

I have made a new version of the AES ciphersuite draft available.  It
can currently be downloaded from:

ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/draft-ietf-tls-ciphersuite-02.txt

In addition, the version on the IETF website should be updated soon.

Please let me know any comments which you have.  The major changes
with this update are:

1.  A ADH ciphersuite is now included (which is not deprecated), with
    an appropriate security warning at the end of the document.

2.  The document now indicates what an implementation must do in order
    to be interoperable.  Of course, any two TLS implementations
    should be interoperable, regardless of whether they implement AES.
    However, I want to ensure that two TLS implementations supporting
    AES can always negotiate an AES ciphersuite.

-- 
Pete

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

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

---

From: Pete Chown <[email-masked]>
Date: Wed, 6 Dec 2000 11:48:06 +0000

Tord Persokrud (ETO) wrote:

> Pete, concerning your point 2 below, i.e. always ensuring that two
> TLS implementations supporting AES can interoperate. It would be
> good, from our point of view that even our most restricted clients
> supporting TLS and AES could conform to this document.

Unfortunately if the interoperability requirements are reversed it
creates a problem for the web people.  Suppose I am very concerned
about security so I want to use forward secrecy in my web browsing.  I
can choose to support only that ciphersuite, whereupon the server is
forced to accept the extra processing load associated with it.

I assume (because you are from Ericsson) that you are concerned about
the opposite problem.  You are producing mobile devices that don't
have the processing power to do forward secrecy.

One point that occurs to me is that if I am browsing the web with a
mobile device, and the server insists on forward secrecy, the
negotiation will take twice as long and I am going to be pretty
frustrated.  So the server operators will have an incentive to offer a
static ciphersuite in order to keep their customers happy.

In the opposite case this doesn't work, because when I am using a
server I am only one of hundreds of other users.  So the extra
processing load that I create is not noticeable to me.  Everyone
experiences a small drop in performance, rather than it being that I
personally experience a big one.

The other point is that the MUST ciphersuites don't apply if an
"application profile standard" specifies some other interoperability
rule.  If you were producing a mobile-specific protocol you could do
exactly this.

Comments appreciated as always...

-- 
Pete

---