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 <n...@cryptonector.com> > 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 -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
