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

[Nico Williams <[e-mail]>]

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.

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.

If it's at all possible to move this timestamp into an authenticator at
this point, I think that's the best solution.

Nico
--