Re: [TLS] Thoughts on TLS 1.3 cryptography performance

[Trevor Perrin <[e-mail]>]

On Wed, Mar 12, 2014 at 11:26 PM, Nico Williams <[e-mail]>wrote:

> 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:
>
> > 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


Not necessarily.  The cached session key doesn't need to be the same as the
session key for previous sessions.  And 0-RTT resumptions could have a DH
exchange overlaid on the 1st RT, so they get PFS after that RT.



> and the
> attacker can impersonate the client in future resumptions regardless
> of past PFS use.


And impersonate the server to the client.



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

On the other side of the balance - doing 0-RTT resumption based on session
tickets saves at least 1 DH compared to the 0-RTT flow in EKR's draft or
QUIC.  If clients need to re-authenticate with something like ChannelID, it
might save a second asymmetric op.  Seems worth considering.


Trevor