Simon Josefsson <simon@josefsson.org> wrote:
> Eric Rescorla <ekr@networkresonance.com> writes:
> 
> > What I'm saying is that the recommendation to prevent his attack
> > is to use an RSA_DHE ciphersuite
> 
> I agree with that.  However, if I remember correctly, DHE key
> exchanges are generally slower than plain RSA key exchanges with
> temporary keys, although it depends on the DH group size.

This is discussed pretty extensively in "SSL and TLS". From memory, on
the server side there are three time consuming steps in the ephemeral
RSA computation:

 1. Generating the ephemeral RSA key
 2. Signing the ephemeral RSA key with the static RSA key.
 3. Decrypting the PMS encrypted under the ephemeral RSA key.

The first can be amortized over a large number of transactions,
so really we're talking about (2) and (3). 

In RSA-DHE, there are three costs as well:

 1. Generating the DH ephemeral.
 2. Signing the ephemeral DH key with the static RSA key.
 3. Computing the DH ZZ.

However step 1 can actually be made quite fast by using a short DH
exponent and/or using a squaring table, so the dominant costs are
(2) and (3). (2) is obviously the same, which leaves us with (3), 
which is comparable in both cases.

So, on the server side, the costs are fairly comparable. On the
client side, DHE is much more expensive since you need to do
(1) and (2). But the cost of one computation is typically relatively
small compared to people's perceptual times (order 50 ms) and
clients tend to be low volume, so it's not an issue except for 
very slow machines.


> > and use a fresh DH ephemeral with each key exchange. This provides
> > the same security at a substantially superior performance level.
> 
> Generating a fresh DH ephemeral with each key exchange would deplete
> the entropy in many RNG's.

I don't understand this point. Most TLS implementations use the
PRNG to generate the random values as well as the session IDs.
You quickly get to the point where you've exposed vastly more
bits of entropy than your underlying PRNG state. If your
PRNG can't handle this, you need a new PRNG.


> Perhaps we could discuss the frequency that DH ephemeral's should be
> changed, possibly also in the document.
> 
> There are tools out there that use a static hard-coded DH ephemeral in
> the code, and some configurations where the DH ephemeral is stored in
> a separate file, but never re-freshed anyway.

DH has two parts:

1. The group parameters.
2. The ephemeral share (g^x mod p).

The group parameters never need refreshing. The ephemeral share
needs to be secret so hardcoding it sees like a pretty bad idea.
Standard practice is to generate a fresh ephemeral for every
connection but you can amortize if you're careful. In particular,
you have to worry about small subgroup issues so it starts to
get a lot more important to use S-G primes.

I can try to draft up some guidance here based on Zuccheratto's 
S/MIME draft, but if someone (Bodo?) wanted to contribute some
text, I wouldn'tcomplain :)

-Ekr

 


_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls