Re: [TLS] Thoughts on TLS 1.3 cryptography performance

[Watson Ladd <[e-mail]>]

On Wed, Mar 12, 2014 at 9:54 PM, Nico Williams <[e-mail]> wrote:
> Isn't session resumption with session tickets faster still and
> -provided the insufficiency of binding from resumed to original
> session is fixed- as secure?  Ah, you want PFS even on resumption, but
> surely that could be added, and even then the result should still
> perform even better than your proposal.

 The performance gain doesn't work like that. It's not from the client
having seen the g^a before, but that the server doesn't need to sign a
new value every time it does a handshake. The client can avoid
validations if it can remember a global database of public
information, but if not it is only slightly worse off then today in
calculation.

By contrast resumption only works if the client maintains some data
that has to be kept secret, and if the server still remembers how to
read the tickets that it handed out. Having resumption doesn't stop
servers going to ECDHE and ECDSA for efficiency reasons. Particularly
at higher security, RSA is extremely slow: my computer can only do 111
RSA 4096 signatures a second. It can do 24 times as many P521
signatures. Even if a small minority of all connections require a
public key operation, that difference matters. (Signatures are
equivalent to decryption, in case people were wondering about RSA
handshakes sans PFS)

Adding PFS to resumption requires two exponentiations client and
server side: one fixed base, one variable base. At that point we've
done enough work to completely redo the connection with HMQV. (well,
modulo the client regenerating its key periodically, or maybe once per
connection for anonymity, and I've ignored the fact that in genus 2 or
on Kummer varieties you have a problem with HMQV and have to do triple
DH instead) I don't see anyone paying that penalty anytime soon.

But don't take my word for it: from Cloudflare: "Because ECDSA is so
much more efficient for our servers, supporting these certificates is
an essential step for enabling SSL for free in 2014." CPU matters.

Sincerely,
Watson Ladd

>
> Nico
> --


-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin