Subject: [ietf-tls] AES ciphersuites (was Proposed New Charter)

From: David Hopwood <[email-masked]>
Date: Sun, 01 Oct 2000 21:19:46 +0100

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

Pete Chown wrote:
[snip]
> > A better reason for not considering RC4 sufficient, is that the public
> > cryptographic community has more experience in analysing the security
> > of block ciphers than stream ciphers.
> 
> Hmm, that's an interesting one.  I've often thought myself that RC4 is
> too simple to be really secure...  IMHO this type of comment does not
> belong in the RFC, though.

No, it doesn't (hopefully analysis of stream ciphers will catch up to some
extent).

[...]
> > Despite that, I think it would be a good idea to also include
> >
> >        CipherSuite TLS_DHE_DSS_WITH_RC4_128_SHA = { 0x00, 0x66 };
> >        CipherSuite TLS_DHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x67 };
> >
> > in the draft.

On second thoughts, I'll withdraw the suggestion of
TLS_DHE_RSA_WITH_RC4_128_SHA. The reason is that a client has to include
a DHE_DSS ciphersuite (TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA) in the client
hello in order to guarantee interoperability [*]. If it includes two key
exchange algorithms, an attacker will have a choice of which to break.
Because of this, and because DSS signing is faster than RSA signing,
there there is not really any advantage in adding new DHE_RSA ciphersuites.

(There might be an advantage if it was mandated that servers support more than
one algorithm - preferably based on independent PK cryptosystems, e.g. DHE_DSS
and Elliptic Curve DHE with ECDSA - so that the client could effectively
choose which to use. However, that should probably wait until the next version
of TLS.)

On the same grounds, I suggest only defining TLS_DHE_DSS_WITH_AES_128_CBC_SHA
for the time being. I.e. the new ciphersuites would be:

    CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x2F };
    CipherSuite TLS_DHE_DSS_WITH_RC4_128_SHA     = { 0x00, 0x66 };

[*] Strictly speaking, the spec only says that
    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA has to be implemented, not that
    clients and servers have to be able to negotiate it. However, I
    think most client writers have interpreted that as meaning that
    this ciphersuite "SHOULD" be in the client hello.

> > The first of these was defined at the same time as the 56-bit
> > ciphersuites (although it is not an export ciphersuite). The second is new;
> > it's just the same thing for RSA signing keys.
> 
> I think these ciphersuites make sense, along with Blowfish ones.
> Unfortunately the goal at the moment seems to be to give the AES
> ciphersuites priority.

TLS_DHE_DSS_WITH_RC4_128_SHA is already implemented by several TLS clients
and servers, so I'm not sure why there would be any point to a delay in
documenting it. Does anyone object to it being included in the draft?

As for Blowfish, the AES winner is being announced tomorrow (Monday 2nd),
so we'll have more information then to decide whether it is worth adding
ciphersuites for both Blowfish and AES.

> > >      The overall strength of TLS is such that
> > >      there is no gain from using a key length longer than 128 bits.
> >
> > OTOH, there is no loss of speed from using 256-bit keys either (except
> > in the case of Rijndael). I'll have to have a look at the AES candidate
> > key schedules more closely, to see whether there would be any advantage
> > in using 256-bit keys (brute force attacks aren't significant for these
> > key lengths, but other attacks might be).
> 
> I've kicked this one backwards and forwards in my own mind.  My old
> draft had 256-bit keys, but then I changed my mind when I thought
> about the security of the rest of the system.

Yes, the Finished hashes are 96 bits, for example. Might as well wait until
we know what AES is until deciding.

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

---
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: Mon, 2 Oct 2000 19:30:46 +0100

So it's Rijndael!  Why did they have to choose the one algorithm with
an unpronounceable name?  :-)

I do like the 256-bit blocks though.  It will be cool to be able to
have a 256-bit hash by using Rijndael as a compression function.

Anyway, back to the hard work...  There is another version of my AES
ciphersuite draft at the usual URL:

ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/

There is lots more text, but no really significant changes.  I have
included the intellectual property statements from Rijndael in the
draft, and included a reference to the Rijndael paper.  There are also
a few typos fixed.

BTW, does anyone know if the Rijndael paper was ever published in a
proper journal?  At the moment all I've got is the URL on the NIST
site, and that could go away.  It would be nice to be able to refer
people to a paper journal that is likely to remain in libraries for a
reasonable time.

> there there is not really any advantage in adding new DHE_RSA

One problem is that DSA certificates never really took off, so there
is a practical advantage to adding a new RSA ciphersuite.

Also, because DSA verification is slower than RSA there may be
circumstances where it is useful.  In the https scenario, it is best
to have efficient signing because the verification load is distributed
amongst all of a web site's clients.  However, in other scenarios the
objective may be to minimise the overall amount of processing.  For
example in TLS-secured CORBA, there is probably no reason to push
processing onto either the client or the server -- they are often
peers.

> documenting it. Does anyone object to it being included in the draft?

I do...  :-)

Seriously, though, I had two reasons for leaving it out, along with
the other ciphersuites that were in my original draft.  Firstly there
seemed to be a lot of disagreement about how the other ciphersuites
ought to work, so I doubted whether the necessary consensus could be
achieved.  Secondly I was going by Win's comment that he wanted the WG
to consider the AES ciphersuites separately
(http://www.imc.org/ietf-tls/mail-archive/msg04403.html if you are
interested).

Actually I don't know how happy I'd be about new RC4 ciphersuites
anyway.  Calling RC4 "Arcfour" and saying that it is free of IP claims
is just the sort of thing that makes corporate lawyers nervous.  But
if we defined RC4 ciphersuites, implementations would appear that only
implemented, say, 3DES and RC4.  Then if you wanted to interwork you
would have to choose between "slow" and "legally dodgy".

> ciphersuites for both Blowfish and AES.

Well, it's Rijndael.  Perhaps we should have Blowfish because everyone
knows how to pronounce that!  :-)

-- 
Pete

---

---

From: Eric Rescorla <[email-masked]>
Date: 02 Oct 2000 12:31:51 -0700

> draft, and included a reference to the Rijndael paper.  There are also
Please submit this as an I-D.

-Ekr

---

---

From: Dr S N Henson <[email-masked]>
Date: Mon, 02 Oct 2000 21:16:22 +0100

> is a practical advantage to adding a new RSA ciphersuite.

Also almost all servers will have an RSA certificate to support
browsers,
if they have to obtain (or purchase) a new DSA certificate each year 
this could discourage the use of AES ciphersuites.

> processing onto either the client or the server -- they are often

Another case if where the client platform is relatively slow. The
enforced use of DSA verification could significantly affect 
performance.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

---

---

From: "Andreas Sterbenz" <[email-masked]>
Date: Tue, 3 Oct 2000 10:06:28 +0200

> ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/

I think this is a fine draft, but I am in favor in adding an AES
ciphersuite with an RSA key exchange as well, i.e.
TLS_RSA_WITH_AES_128_CBC_SHA. While some may believe the additional
overhead of ephemeral ciphersuites is not significant, I believe we
cannot assume this will be the case for all applications.

Forward secrecy is of course an argument, but I would like to see the
server key exchange message be allowed for the RSA key exchange anyway.
Some implementations already accept it by the way. But this does not
really have anything to do with AES.

Regards,

 Andreas Sterbenz              mailto:[email-masked]

---

---

From: Pete Chown <[email-masked]>
Date: Tue, 3 Oct 2000 10:34:43 +0100

Eric Rescorla wrote:

> Please submit [the AES ciphersuite draft] as an I-D.

Good idea -- now done.  I will send another message to the list once
it is available from the Internet Drafts directory.

-- 
Pete

---

---

From: Dr S N Henson <[email-masked]>
Date: Tue, 03 Oct 2000 17:07:53 +0100

> cannot assume this will be the case for all applications.

Yes I suppose there's the client overhead to consider again for low
powered clients. The client DH operations are considerably slower than
the corresponding RSA encrypt and verify operations.

> really have anything to do with AES.

This is a bit of a problem because the TLS spec bans the use of server
key exchange except for certain export ciphers. If AES ciphersuites
existed supporting RSA key exchange then I suppose the key exchange
message could be specifically permitted. That wouldn't help already
existing ciphersuites though.

Steve.

---

---

From: Eric Rescorla <[email-masked]>
Date: 03 Oct 2000 09:33:22 -0700

> existing ciphersuites though.
Steve, 

I think you're misreading Andreas's message. If I read it correctly,
He doesn't want Ephemeral RSA. He wants static RSA, which isn't 
in the draft. 

I totally agree here.

On the other hand, the value of ephemeral RSA strikes me as minimal.

-Ekr

---

---

From: Jeremey Barrett <[email-masked]>
Date: Tue, 3 Oct 2000 11:46:40 -0500

> cannot assume this will be the case for all applications.

I'd really like to see this as well. In fact, with RSA unencumbered,
I'd like to see some (non-ephemeral) RSA as a MUST. Perhaps
TLS_RSA_WITH_AES_128_CBC_SHA would be a good candidate?

Regards,
Jeremey.
-- 
Jeremey Barrett [[email-masked], [email-masked]]
GnuPG fingerprint: 7BB2 E1F1 5559 3718 CE25 565A 8455 D60B 8FE8 B38F

---

---

From: Dr S N Henson <[email-masked]>
Date: Tue, 03 Oct 2000 18:17:49 +0100

> > > > server key exchange message be allowed for the RSA key exchange anyway.

suggested support for ephemeral RSA, can you clarify that Andreas?

> On the other hand, the value of ephemeral RSA strikes me as minimal.

Well depends on what the application is. Low powered clients is one
case, but if were allowing static RSA IMHO we shouldn't specifically
prohibit the server key exchange message as is currently the case with
non export ciphers.

If server's don't want to use it they don't have to but clients should
be able to handle it, as they would already do with already existing
export ciphers.

Steve.

---

---

From: Eric Rescorla <[email-masked]>
Date: 03 Oct 2000 10:26:00 -0700

> suggested support for ephemeral RSA, can you clarify that Andreas?
You're right. I think what he may be saying that 
(1) He'd like static RSA.
(2) he'd like to allow ephemeral RSA.

> prohibit the server key exchange message as is currently the case with
Honestly, I'd like to get rid of ephemeral RSA entirely. It's no
longer necessary for export cipher. If we want to have a PFS mode,
that's what DH is for.

I understand the "low powered client" argument, but I tend to
discount it. By the time we get to RFC, clients will be much
faster :)

-Ekr

---

---

From: Dr S N Henson <[email-masked]>
Date: Tue, 03 Oct 2000 19:16:04 +0100

> longer necessary for export cipher. If we want to have a PFS mode,

I agree though that DH is best suited for PFS in most circumstances.
However in the few where it isn't I'd like to see some standard way of
allowing ephemeral RSA without having to violate the specs or resort to
"local hacks".

> discount it. By the time we get to RFC, clients will be much

I wouldn't like to bet on Palms being obsolete by then :-)

Steve.

---

---

From: Ben Laurie <[email-masked]>
Date: Tue, 03 Oct 2000 20:13:09 +0100

> longer necessary for export cipher. If we want to have a PFS mode,

Or would be if anyone implemented it!

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/

---

---

From: [email-masked] (Nelson Bolyard)
Date: Tue, 03 Oct 2000 12:43:57 -0700

> cannot assume this will be the case for all applications.

I agree.  I very much want to see TLS_RSA_WITH_AES_128_CBC_SHA in addition
to the others already proposed.

--
Nelson Bolyard               Sun / Netscape Alliance

---

---

From: "Baber Amin" <[email-masked]>
Date: Tue, 03 Oct 2000 13:55:59 -0600

I agree that ephemeral cipher suites though my personal favorite do tend to add more overhead, that Irather not add.

Baber Amin

>>> [email-masked] 10/03/00 01:43PM >>>

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

---

---

From: Dr S N Henson <[email-masked]>
Date: Tue, 03 Oct 2000 21:13:51 +0100

> Or would be if anyone implemented it!

And if those that implemented broken versions fixed it when it was
obvious they were wrong...

Steve.

---

---

From: "Andreas Sterbenz" <[email-masked]>
Date: Wed, 4 Oct 2000 11:11:31 +0200

> (2) he'd like to allow ephemeral RSA.

Yes, that is what I meant. Sorry if it was unclear.

I do not know if we really want or need ephemeral RSA. In any case it is
trivial to support for all (client) implementations that can do
exportable RSA. That seems to make it at least worth considering,
although it is in violation of the TLS spec a lot of people implemented.

Regards,

---

---

From: Pete Chown <[email-masked]>
Date: Wed, 4 Oct 2000 11:08:35 +0100

I've noticed that a non-ephemeral RSA/AES ciphersuite has a lot of
support.  I want to spend a bit of time on this one, to work out what
the actual performance benefits are.  Unfortunately I am going to be
away on a business trip for a few days so I won't be able to respond
in detail until next week.

In the meantime, am I right that people want this ciphersuite *just*
because of performance benefits, or are there other advantages too?
(I can't think of any; I just want to make sure.)

I feel a bit uneasy about the non-ephemeral ciphersuite because it is
definitely less secure than the EDH one.  I worry that people will
only implement the less secure ciphersuite, so diluting the usefulness
of adding the AES.

> TLS_RSA_WITH_AES_128_CBC_SHA would be a good candidate?

I would certainly like to see at least one MUST ciphersuite from among
the AES ones, but I don't think it is feasible.  Suppose someone has a
TLS implementation that conforms to the original RFC.  We can't
suddenly declare that it doesn't conform any more because we have
"changed our minds" about what constitutes TLS.

I would like to be proved wrong on this, but I can't see any way out
of it myself.

-- 
Pete

---

---

From: Dr S N Henson <[email-masked]>
Date: Wed, 04 Oct 2000 13:03:39 +0100

> only implement the less secure ciphersuite, so diluting the usefulness

Well I'm not sure what the consensus on it being ephemeral is.
Personally I'd say we should have an RSA/AES cipher suite and remove the
TLS restriction on server key exchange: that is it *may* be ephemeral if
the server wishes.

Can others who expressed support also indicate whether the would ban
server key exchange (as is the case with other cipher suites) or allow
it?

This places the additional requirement on the client: it MUST handle the
server key exchange message if it is present. Currently TLS bans the use
of this message for RSA key exchange in anything but certain export
ciphers.

Implementing this is relatatively easy to an already existing "RSA only"
client. If it handles the usual export crippled ciphersuites it should
simply be a case of stopping it choking when it sees server key exchange
and adding AES.

To get any useful performance out of a server using ephemeral RSA it
would need to cache RSA temporary keys, however if it supports the
export ciphersuites it may well be doing that anyway.

In terms of client side peformance if I understand the process correctly
the contrast is dramatic. An ephemral DH cipher suite will do (among
other things) something like this client side:

1. Verify signature of server key exchange and server chain.
2. Generate a DH key pair.
3. Determine the DH shared secret.

For DSA authentication operation 1. is expensive, for RSA it is not. 2
and 3 are expensive operations. For ephemeral RSA it will do:

1. Verify signature of server key exchange and server chain.
2. Encrypt premaster secret using server temporary key.

Neither is expensive for RSA certificates.

In the case of a low power client this could be crucial. People are
doing SSL/TLS on things like Palm Pilots which might take 30s or more to
do the epehemeral DH operations. This is enough to discourage the use of
AES ephemeral DH ciphersuites completely. If we allow RSA it can have a
much smaller overhead. If we also allow server key exchange it can also
have forward secrecy: something which none of the other RSA strong
ciphersuites supports.

Steve.

---

---

From: Peter W <[email-masked]>
Date: Wed, 4 Oct 2000 09:31:44 -0400

> > I feel a bit uneasy about the non-ephemeral ciphersuite

Me, too.

> TLS restriction on server key exchange: that is it *may* be ephemeral if

Optional, specified by the server? I think that may be the wrong way to
go about it.

We currently have a chicken-and-egg problem with ephemeral TLS/SSL3
suites, with neither Microsoft nor Netscape supporting ephemeral suites
for https on the server or client end. Allowing the server to say
whether to spec ephemeral would allow the relatively few server vendors
to continue to avoid ephemeral support and forward secrecy.

So I think the server should be required to support ephemeral suites.
This would break the client-vs-server ephemeral support stalemate and
allow TLS client vendors to provide more secure applications without
fearing that they're wasting their time. Yes, there will be a lag time,
but I think it may be the only way to make forward secrecy obtainable.

> the contrast is dramatic.

> have forward secrecy: something which none of the other RSA strong

If there's little difference on the client end for ephemeral RSA, and
caching of keys on the server end can conserve resources there, then I
think that ephemeral is clearly the way to go. Anything on which a
server cert is installed should have the resources to periodically
regenerate temporary keys.

-Peter

-- 
This fall, taxpaying American citizens will elect voting representatives to
the US Congress. Except for those in Washington, DC. http://www.dcvote.org/

---

---

From: Eric Rescorla <[email-masked]>
Date: 04 Oct 2000 07:32:33 -0700

[Ephemeral DH]
> of this message for RSA key exchange in anything but certain export
We can't remove this restriction for the current ciphers because
that would declare current implementations nonconforming. We can remove
it for all new ciphers.

> export ciphersuites it may well be doing that anyway.
This concerns me. If the purpose is forward secrecy then the
key can't be cached for very long (minutes, hours)? In any
case you won't have _perfect_ forward secrecy if you cache it
at all, since the attacker could notice that you had engaged in
a transaction he cared about and attack your machine at that point.

> Neither is expensive for RSA certificates.
Quite right. Last time I measured it, DSS/DHE was something
like 20 times more expensive than static RSA for the client. Thus
about 10 times more expensive than ephemeral RSA.

-Ekr

---

---

From: "Andreas Sterbenz" <[email-masked]>
Date: Wed, 4 Oct 2000 16:45:33 +0200

> TLS restriction on server key exchange: that is it *may* be ephemeral
if

There are three options not causing problems with current
implementations:
 (a) Allow ephemeral for the new AES ciphersuites only
 (b) Wait for the next protocol version and allow it for all ciphersuites
 (c) Use the extension mechanism

I favor (a) but would probably still like (b) when the time comes.

Another question is if we want to leave it up to the server to decide
whether to use static or ephemeral RSA. If not we could again use the
extension mechanism. I do not have a firm opinion about this.

Regards,

---

---

From: Preda Mihailescu <[email-masked]>
Date: Wed, 04 Oct 2000 17:16:46 +0200

Hi,

I read some performance concerns about discrete logarithm based schemes (DH, DSA) along this thread.
So I would like to point out that it is possible to uses such schemes in Galois extensions, rather then
prime fields. By according choice of the extension and arithmetic bag of tricks, one achieves important
improvements. Thus, for ~ 1024 bit key security, the improvement factor is at least 10 (thus also improving
upon RSA for the same key size). This approach is coevered by the IEEE P1363a cryptography standard
draft.
The arithmetic is only descirbed in an unpuiblished paper and I am currently writing a more comprehensive
update. I can provided more detail for interested questions.
It may also be worhtwhile considering to reserve some ciphersuites for TSL using Galois extensions, given
these nice to have performance qualities.

--- Preda

PS:
The last message was a test, verifying that my previous 2 ones had not reached the list (sorry for the confusion :-(

---

---

From: Dr S N Henson <[email-masked]>
Date: Wed, 04 Oct 2000 17:29:50 +0100

> to continue to avoid ephemeral support and forward secrecy.

Well currently with strong RSA cipher suites there is no choice. I
believe the SSL spec was ambiguous on this point and TLS specifically
prohibits the use of server key exchange. As such there is no standard
to use ephemeral RSA with strong encryption.

I know of at least one client vendor that would like to support
ephemeral RSA if a standard existed.

> but I think it may be the only way to make forward secrecy obtainable.

I'm not particularly opposed to making ephemeral RSA server support
mandatory.

I would say however that the differences on the client side between
supporting static only AES and ephemeral/static AES are likely to be
minimal if it supports the existing export cipher suites. 

IMHO this lesser requirement of only mandating client support would be
sufficient to break the stalemate and server vendors or writers could
then support ephemeral RSA, possibly pressured by some freeware servers
supporting it.

Steve.

---

---

From: Dr S N Henson <[email-masked]>
Date: Wed, 04 Oct 2000 17:31:24 +0100

> that would declare current implementations nonconforming. We can remove

Yes I meant that. I should've been clearer that the removal of the
restriction can only apply to the new AES ciphersuite.

> a transaction he cared about and attack your machine at that point.

Yes ephemeral DH doesn't need to store the DH key pair and can use each
key only once. However a server will typically include a session cache
if it wants reasonable performance. An attacker might be able to
retrieve or have access to the session cache's master secret and attack
that instead.

Admittedly though it is practiable to run ephemeral DH without a session
cache, albeit with a big performance hit. This isn't true for ephemeral
RSA due to the much longer key generation time.

In any case even if the temporary RSA key does last an hour that is a
vast improvement on the static RSA version which will typically have the
same key in use for a year or so.

Steve.

---

---

From: [email-masked] (Nelson Bolyard)
Date: Wed, 04 Oct 2000 14:42:35 -0700

> of this message for RSA key exchange in anything but certain export

I think you're proposing that use of server key exchange to provide ephemera
be "optional", and that the server may choose to use it, or not, as it wishes,
within a given cipher suite, 

I very much dislike that idea.  I believe that the use of a server key 
exchange ought to be required, or prohibited, as part of the definition
of the cipher suite.  

If we want to allow a choice (ephermeral, or not), then we should define two
cipher suites, one with SKE, one without.

That way, a client can tell the server whether or not it supports the use of 
the SKE message by the choice of cipher suites it offers in the client hello. 
If the client wants to require, or prohibit, the use of the SKE, it simply 
includes the cipher suites in its client hello message accordingly.  
Likewise, when the server picks a cipher suite, it would be explicitly
specifying whether or not an SKE is to be done.

This approach doesn't change the definition of any of the existing cipher
suites.  A client that doesn't support SKE with existing non-export cipher
suites would not suddenly be non-compliant.

I would like to see cipher suites defined, both with and without the SKE.

--
Nelson Bolyard               Sun / Netscape Alliance
Disclaimer:                  I speak for myself, not for Netscape

---

---

From: [email-masked] (Nelson Bolyard)
Date: Wed, 04 Oct 2000 15:35:22 -0700

Content-Transfer-Encoding: 7bit

Eric Rescorla wrote:
> 
> [email-masked] (Nelson Bolyard) writes:
> We already have quite a bad combinatoric explosion problem. Why
> make it worse?

With the Diffie-Hellman cipher suites, the use (or not) of ephemera is 
already coded as part of the cipher suite definition (e.g. DHE_ vs DH_).

I merely propose that cipher suites be consistent in this regard, rather
than having any "special case" cipher suites.

Advantages of my proposal include:
a) giving both the client and server control (via negotiation) on the use
(or not) of ephemera.  Clients can effectively require it if they choose.

b) By removing any "optional" behavior from the cipher suite, it is easier
to prove/demonstrate the correctness of any implemenation.  

IMO, two products are more likely to succesfully interoperate if there is 
"optional" behavior to the cipher suite.  

(OK, I realize that the server's request for client authentication is still
an "optional" behavior of SSL/TLS.)

c) This scheme doesn't require all TLS clients to support SKEs.  
"Lightweight" clients should appreciate that.

---

---

From: Eric Rescorla <[email-masked]>
Date: 04 Oct 2000 15:48:14 -0700

> (or not) of ephemera.  Clients can effectively require it if they choose.
No they can't. The server can always just use some essentially static
key as his ephemeral key. The only thing the client can actually force is
doubling the server's workload. I'd point out that this is exactly what
many servers do with "ephemeral" RSA today.

> "optional" behavior to the cipher suite.  
TLS is already so complicated that I don't think this makes much of a
difference. 

> "Lightweight" clients should appreciate that.
The code to implement SKE is trivial compared to the rest of the
SSL code. Moreover, many implementations will need to support
SKE in any case to support old export modes.

The primry disadvantage of this approach is that it makes the
already quite bad combinatoric explosion problem even worse. 

-Ekr

---

---

From: Eric Rescorla <[email-masked]>
Date: 04 Oct 2000 15:20:06 -0700

-Ekr

---

---

From: [email-masked] (Nelson Bolyard)
Date: Wed, 04 Oct 2000 15:55:35 -0700

> already quite bad combinatoric explosion problem even worse.

It doesn't make RSA any worse than DH.

It only makes the distinction between ephemeral and non-ephemeral RSA be no
different than the distinction between ephemeral and non-ephemeral DH.

---

---

From: Eric Rescorla <[email-masked]>
Date: 04 Oct 2000 16:02:44 -0700

> It doesn't make RSA any worse than DH.
Correct, but the DH situation stinks. 

> different than the distinction between ephemeral and non-ephemeral DH.
With DH, this distinction was marginally understandable because supporting
DH certificates was rather different from supporting DHE. Most 
implementations already support SKE for RSA, so this doesn't add
any additional implementation burden at all. 

What the change you suggest does do is create a needless opportunity for
interoperability problems.

-Ekr

---

---

From: Dr S N Henson <[email-masked]>
Date: Thu, 05 Oct 2000 00:10:05 +0100

> different than the distinction between ephemeral and non-ephemeral DH.

Except that static DH ciphersuites are very rarely implemented (anyone
know of *anything* that supports them?) whereas it would be hoped that
ephemeral and non ephemeral RSA would be widely used.

Anyway some export ciphersuites do something similar except of course
that the conditions under which SKE is present are well defined
and not at the servers disgression. However it can still result in one
ciphersuite which sometimes uses SKE and sometimes does not.

Steve.

---

---

From: Dr S N Henson <[email-masked]>
Date: Thu, 05 Oct 2000 00:14:16 +0100

> interoperability problems.

It also gives the opportunity of preserving the current situation of
lack of forward secrecy in "browser SSL/TLS" which was one of my
motivations for suggesting it or an equivalent alternative.

Steve.

---

---

From: Eric Rescorla <[email-masked]>
Date: 04 Oct 2000 16:20:38 -0700

> motivations for suggesting it or an equivalent alternative.
Steve, I'm having a bit of trouble understanding your argument here.

Can you restate it? 

Thanks,
-Ekr

---

---

From: Dr S N Henson <[email-masked]>
Date: Wed, 04 Oct 2000 23:15:37 +0100

> within a given cipher suite,

I wasn't suggesting the existing ciphersuites should be changed in any
way. I was suggesting that the new AES ciphersuites only should have
this property.

> I would like to see cipher suites defined, both with and without the SKE.

What I wanted to avoid is the current situation where no strong
encryption forward secrecy ciphersuites are generally usable. I'm not
too concerned about how this is achieved in practice.

I suppose an alternative would be to define SKE and non SKE ciphersuites
and then state that they MUST both be supported, then leave it down to
client and server preferences.

Steve.

---

---

From: David Hopwood <[email-masked]>
Date: Thu, 05 Oct 2000 03:01:16 +0100

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

Eric Rescorla wrote:
> > a) giving both the client and server control (via negotiation) on the
> > use (or not) of ephemera.  Clients can effectively require it if they
> > choose.

> No they can't.

Yes they can, if the standard mandates that ephemeral keys with a specific
maximum lifetime be used with that ciphersuite. (Obviously we can only talk
about what is guaranteed for conforming implementations.)

- -- 

---

---

From: Eric Rescorla <[email-masked]>
Date: 04 Oct 2000 21:43:35 -0700

> about what is guaranteed for conforming implementations.)
Specifying any form of key hygiene requirement would be a substantial
departure from current TLS practice. We don't even specify the 
maximum lifetime for 512 bit keys, despite the fact that they were
known to be weak at design time.

-Ekr

---

---

From: Peter W <[email-masked]>
Date: Thu, 5 Oct 2000 14:03:49 -0400

> > about what is guaranteed for conforming implementations.)

And the whole point of ephemera was forward secrecy.

With extra work on the client side, the RSA premaster secret exchange
could be modified to give the client some control over forward secrecy.
The client could use its own keypair (if client cert auth is being used,
or the client doesn't care about anonymity) or a temporary RSA keypair (if
no client cert used, or for extra safety) so that each party (client and
server) would suggest half of the premaster secret and encrypt its
suggestion with the other party's public key. An attacker would need
access to either application's memory space (an attack vector TLS can
never protect against) or access to both parties' keypairs (in which case
there are probably bigger problems). With one party's key info, an
attacker would have a much smaller premaster secret to dissect, but still
would need to do some work.

This would also help protect the communications from weak pseudorandom
number generators. Maybe the client is using a Palm device that doesn't
have the resources to pick a good premaster secret, but the server has a
very well implemented PRNG mechanism. With the current system, you need
either the server keypair (thus the talk about ephemera) or the premaster
secret created by the client. Hopefully everyone learned from Netscape's
early blunders, but I wonder if all these new mobile devices can be
trusted to pick good secrets.

Leaving aside the issue of how radically this would change the protocol,
how does the expense of the client decrypting half the premaster secret
compare to, say, DH calculation? How good are the PRNG on the client
devices where DH is unacceptably slow? Would it make sense to increase the
premaster secret size?

Client keypair generation time would also be an issue, for privacy
reasons, for connections where client certs are not used. If a client
reused the same temporary public key with multiple TLS servers, those
servers would then have a common identifier with which they could share
information about the client. :-(

But if a client cert is being presented, then there is no keypair
generation involved, and no expectation of privacy, so the only issue is
whether the group feels forward secrecy is important enough to change the
protocol significantly.

If not, then there's no practical way of guaranteeing forward secrecy with
RSA premaster secret exchange.

> known to be weak at design time.

Perhaps that ought to be specified?

-Peter

---

---

From: Eric Rescorla <[email-masked]>
Date: 05 Oct 2000 11:16:45 -0700

> And the whole point of ephemera was forward secrecy.
Actually, no. Historically the purpose of ephemera was
(1) to permit "domestic" SSL implementations to use a single (long) key
to communicate with "export" implementations.
(2) To allow the use of DH keys with DSA certificates, since the 
number of DSA certificates, while small, is larger than the number
of DH certificates.

PFS was sort of a nice side effect.

> RSA premaster secret exchange.
The same argument that I made earlier applies to DH key exchange as 
well. There's no way of guaranteeing secrecy, forward or otherwise,
in the face of servers which engage in bad security practices. Nowhere
in the spec does it say that the DHE key must be freshly generated for
each transaction.

The point I'm trying to make here is that historically TLS has been
agnostic about specifying good security practices. I don't see
why a draft whose primary purpose is to add AES is the right way
to change that.

-Ekr

---