Subject: [ietf-tls] Re: AES outstanding issues

From: <[email-masked]>
Date: Fri, 5 Jan 2001 17:22:40 -0000

A comment on the suggested requirement for mandatory support of PFS.

> -----Original Message-----
> From: Ben Laurie [mailto:[email-masked]]
> Sent: 11 December 2000 14:13
> To: IETF Transport Layer Security WG
> Subject: [ietf-tls] Re: AES outstanding issues
> 
> 
> Pete Chown wrote:
> > 
> > Okay, these are the outstanding issues that I can see with the AES
> > draft.  Let's go and bang our heads against the wall -- by the time
> > we've been going for a while we will probably be able to 
> imagine that
> > there is some kind of consensus! :-)
> > 
...
> 
> > 2.  Interoperability.  Ericsson are concerned that the current
> >     interoperability rules will force mobile devices to support
> >     forward secrecy when they don't have the processing power to do
> >     so.
> 
> Then they are broken. Forward secrecy should not be optional. 
> We should
> probably allow consenting adults that don't care to configure it away
> though.

If you want to make server support of FS ciphersuites mandatory then fine,
but it should not be mandatory for clients.  Per session key generation will
be a tall order for many mobile devices for some time to come.  As a
compensating factor, GSM and 3GPP mobile devices (unlike most servers) will
have a smartcard that can be used to store the master secret, I would argue
that this lessens the requirement for FS on mobile clients.

Tim

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

---

From: David Hopwood <[email-masked]>
Date: Sat, 06 Jan 2001 00:13:32 +0000

-----BEGIN PGP SIGNED MESSAGE-----

> A comment on the suggested requirement for mandatory support of PFS.
[snip]
> Ben Laurie wrote:

I strongly agree. *Either* the client or server should be able to
insist on forward secrecy, and this requires that *both* support (and
are actually able to negotiate) at least one common FS ciphersuite.

> > We should probably allow consenting adults that don't care to
> > configure it away though.
> 
> If you want to make server support of FS ciphersuites mandatory then
> fine, but it should not be mandatory for clients.

Supporting forward secrecy does not have much effect on the performance of
clients; the main performance effect is on servers (and I think even that
could be almost eliminated by adding some new key exchange methods). IMHO
Ericsson's concern is unfounded. I'll post the performance estimates again
if anyone missed them last time.

> Per session key generation will be a tall order for many mobile devices
> for some time to come.

Clients do not have to generate public/private key pairs in order to
support FS (they obviously have to generate session keys using the PRF,
for all ciphersuites).

> As a compensating factor, GSM and 3GPP mobile devices (unlike most servers)
> will have a smartcard that can be used to store the master secret, I would
> argue that this lessens the requirement for FS on mobile clients.

The point of FS is to protect information sent in previous sessions if
the server's private key is compromised. This requires support for
FS ciphersuites from the client. An anonymous client doesn't store any
long-term keys anyway.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---