Subject: Re: [TLS] DH group validation

From: Mike <[email-masked]>
Date: Wed, 31 Oct 2007 22:03:46 -0700

> To see this, consider a server such as Apache, which operates
> multiple independent processes. There are two ways to have an
> ephemeral key with a limited lifespan: have it shared across
> multiple processes or have one key per process. Obviously
> in the second model a key used for 100 transactions will have
> a much longer lifespan than the first.

Would the use of cached sessions be considered to extend the
lifespan of an ephemeral key?  Or is it just the sessions
where it is used in a full handshake?

Mike

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 01 Nov 2007 00:20:16 -0700

At Wed, 31 Oct 2007 22:03:46 -0700,
> where it is used in a full handshake?

I'm not sure what the question is. Clearly if you have access
to the session cache you can reconstruct the keying material
for any connection using that master secret. If you're
interested in PFS, you need to use short session caches.

-Ekr

---

From: Mike <[email-masked]>
Date: Thu, 01 Nov 2007 07:05:03 -0700

> If you're

Is there any guideline on how short "short" should be?  Is
the recommended upper limit of 24 hours too long?

Mike

---

From: <[email-masked]>
Date: Thu, 1 Nov 2007 16:49:05 +0200

[email-masked] wrote:

> Resurrecting the RSA_EXPORT key exchange mechanism and
> repackaging it as ephemeral RSA (and removing the key length
> restrictions) would solve this problem and there is already
> a body of existing code to do it.  These constrained clients
> could even ditch all their Diffie-Hellman code, saving some
> memory.

I don't think this is within the scope of the TLS 1.2 document.

As a separate draft, maybe (although if the absolute savings
we're talking about are in the same ballpark, or less, than
typical round-trip times, any "160x speedup" in one part
won't have any effect on e.g. user noticeable delay).

Best regards,
Pasi

---

From: Mike <[email-masked]>
Date: Thu, 01 Nov 2007 15:41:58 -0700

> won't have any effect on e.g. user noticeable delay).

My point was that if you're going to consider modifying DHE to
increase client performance, you should also consider moving to
ephemeral RSA.  The code is already there (RSA_EXPORT), and a
few people seem interested in it.  If you choose not to go with
either change, that's fine.

As far as a 160x speedup not being compelling enough, I would
just say that my 3.2GHz machine might not show any user notice-
able performance improvement, but a much slower processor could
easily do the RSA encryption while struggling to do the Diffie-
Hellman computations.  Also being able to support only RSA, and
not both RSA and DH saves on space.

To be complete, I tested the performance of RSA signature
verification to see if that would overwhelm the client.  The
numbers are:

                1024-bit
   size   RSA signature verify   RSA encryption     Total
   1536         0.000438            0.000842       0.001280
   2048         0.000438            0.001405       0.001843

For a Diffie-Hellman exchange:

   size   RSA verify    DH keygen    DH secret    Total
   1536    0.000438      0.06978      0.06968    0.139898
   2048    0.000438      0.15535      0.15286    0.308648

Still a factor of 109 to 167.

Mike