Re: [TLS] Security review of TLS1.3 0-RTT

[Benjamin Kaduk <[e-mail]>]

[replying to the part of your message I did not already cherry-pick and
reply to...]

On 05/02/2017 01:25 PM, Nico Williams wrote:
> On Tue, May 02, 2017 at 11:17:42AM -0700, Colm MacCárthaigh wrote:
>> On Tue, May 2, 2017 at 11:00 AM, Nico Williams <[e-mail]>
>> wrote:
>>> I would think that the ticket itself is enough for that when using
>>> 0-rtt.  I.e., if you don't want connection correlation to be possible,
>>> you can't use 0-rtt.
>> I don't think so. If the ticket is encrypted when it issued, I don't follow
>> how it could be used to correlate the original connection with the 0-RTT
>> connection.
> The ticket's _ciphertext_ is not visible to the eavesdropper when it is
> issued, but it IS visible to the eavesdropper when it is used in 0-rtt.
> The client cannot change the ticket's _ciphertext_.  Therefore the
> eavesdropper can correlate 0-rtt connections when tickets are reused.
> The obfuscated ticket age is irrelevant to that.
>
> Now, I understand that the obfuscated ticket age goes in the clear in
> 0-rtt connections, and that if the attacker could work out the
> unobfuscated time then the attacker could correlate not just the 0-rtt
> ticket-reusing connections with each other, but also some earliere
> ticket-establishing connection(s) observed at that time.
>
> I find the obfuscated ticket age business a bit silly, but maybe I'm
> missing something.  The client should really send an [encrypted]
> authenticator that includes a timestamp, thus allowing the server to
> detect replays and so on -- just like Kerberos.  Then this problem
> wouldn't happen.

It's just to provide a little extra benefit on top of TLS 1.2 of
unlinkability in some situations.  In TLS 1.2, the session ticket was
sent unencrypted, so the ticket ciphertext is always available to the
attacker for correlation of ticket use to the original connection  (and
thus to other resumptions from that original connection).  With TLS 1.3,
the first time the observer sees the ticket ciphertext is when the
client uses it.  If the client only uses the ticket once, the naive
conclusion is that the resumption is not linkable to anything else --
the original connection or other resumptions from the same original
connection.  But, because we have this ticket age anti-replay mechanism,
the ticket age could be used to link resumptions from the original
session together, as described shortly.  This only matters when the
client has multiple tickets to use that were granted at the same
time/session, since if the client is reusing tickets then the ticket
ciphertext links the reuse, as you already noted.  So, if the ticket_age
was in the clear, then the attacker could subtract that to find when the
ticket was issued, and correlate the multiple tickets that were issued
together.  Obfuscating the ticket age prevents that correlation.

That correlation was unavoidable with TLS 1.2 tickets; if you're happy
with the 1.2 behavior, you don't need to care about reusing tickets or
how obfuscated your ticket age is.  (This is Viktor's postfix case, as I
understand it.)

> In any case, given that ticket-reusing 0-rtt connections can be
> correlated with each other, the ability to further correlate them with a
> ticket-issuing connection(s) established earlier doesn't seem to be that
> much more of a big deal.

Agreed.  This whole anti-linkability thing is really in a very narrow
use case, and only when each ticket is used at most once.  (It's also a
very minor benefit, in my mind, compared to the other security
properties in scope.)

-Ben