Re: [TLS] Thoughts on TLS 1.3 cryptography performance

[Nico Williams <[e-mail]>]

On Thu, Mar 13, 2014 at 1:12 AM, Watson Ladd <[e-mail]> wrote:
> 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.

Well, but with resumption the signature validation is also optimized
away for a while.

> 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.  [...]

Ah!  Thanks, that's the key.  It's OK to expect servers to remember
how to read their session tickets.  As for the need to keep session
resumption tickets private on the client side... certainly the client
would have to provide integrity protection to any cache of signature
validations and server public ECDH keys, but ticket compromise is
rather severe: past non-PFS resumptions are compromised and the
attacker can impersonate the client in future resumptions regardless
of past PFS use.  Of course, in your scheme if the client can't
protect its local cache then it's subject to some MITM attacks, but
that's a much smaller concern.

Thanks,

Nico
--