Re: [TLS] Should we support static RSA in TLS 1.3?

[Andy Lutomirski <[e-mail]>]

On Mon, Nov 18, 2013 at 7:20 PM, Geoffrey Keating <[e-mail]> wrote:
> Andy Lutomirski <[e-mail]> writes:
>
>> (For what it's worth, static RSA is faster on the client side than
>> short-term fixed DH certificates, but fixed DH may result in a cleaner
>> protocol.  I suspect that fixed ECDH is quite a bit faster than either.)
>
> I think you'll find fixed ECDH is still slower on the client than
> static RSA.  With 'openssl speed' on this system I find that a 256-bit
> ECDH takes 0.0013s, and two 2048-bit verify/encrypt operations takes
> 2*0.000197s=0.000394s, which is 3.3x faster.  (Of course the
> signing/decryption operations take 2*0.0074s=0.0148s, which is more
> than 10x slower, but that's on the server.)

I wonder how Curve25519 stacks up.

>
> Of course this changes a lot if you have hardware, but more clients
> have RSA in hardware than ECDH in hardware, and if you have to choose
> then it's better to have RSA hardware because you'll probably need to
> do some more RSA verify operations to check the certificate chain.
>
> Fixed DH and fixed ECDH don't give PFS when used in current TLS.
> You could make them do this in a new version of TLS by doing
> ephemeral DH or ECDH or RSA, and then using the fixed DH to agree on a
> key that is used in a MAC to verify the ephemeral DH public key, but
> it's twice as much work (and no-one seems to be using fixed DH anyway).

Google's QUIC almost has PFS -- they achieve it by signing a very
short-lived set of ECDH parameters using their X.509 certificate and
presenting those ECDH parameters, with signature, to the client.  The
client verifies the signature and does one ECDH calculation.

If those parameters are generated at server startup, flushed every
hour or two, and never hit disk, then it works pretty well.  (Whether
it's better than short-lived RSA keys is debatable.)

--Andy