Re: [TLS] Thoughts on TLS 1.3 cryptography performance

[Eric Rescorla <[e-mail]>]

On Thu, Mar 13, 2014 at 10:17 AM, Trevor Perrin <[e-mail]> wrote:

>
> On Thu, Mar 13, 2014 at 9:48 AM, Eric Rescorla <[e-mail]> wrote:
>
>> On Thu, Mar 13, 2014 at 9:34 AM, Nico Williams <[e-mail]>wrote:
>>
>>>  But I am concerned about the need for PFS on
>>> resumption in order to limit the extent of resumption ticket cache
>>> compromise; if you're going to lose the 0-RTT resumption for it, might
>>> as well pick the best "fast reauthentication" protocol possible, and
>>> that might be Watson's.
>>
>>
>> WRT this specific point, I wanted to observe that computational cost
>> (within reason) is less important than round trip delay
>>
>
> True, but a 0-RTT session ticket resumption requires less computation than
> a 0-RTT handshake based on a semi-static ECDH key (like QUIC, or your
> draft) without any RTT tradeoff.
>
> (My understanding of both QUIC and your draft is that in the 0-RTT case
> they perform an "overlaid" DH while exchanging application data in the
> initial RT, so subsequent data gets PFS while the initial RT does not.
>  This could be done with session tickets as well.)
>

Thanks for making this point. I think it gets to precisely the questions we
need
to be asking, namely:

1. Do we want to provide a mechanism for a client and server to form a new
TLS connection without doing any public key operations?

2. Do we want to provide a mechanism for a client and server to do a
0-RTT handshake which minimizes the number of public key operations,
potentially at the cost of linkability. (It's possible to do a 0-RTT
handshake
without linkability if the server uses the same DH key for a lot of clients,
but not if you use the same session ticket repeatedly, though maybe you
could swap the ticket each time.)

-Ekr


> Also: if the semi-static handshake is going to require an expensive client
> re-authentication (ChannelID, PAKE, a slow smartcard, etc.), then the
> savings for resumption are even greater.
>
>
> Trevor
>
>