Seeing as this utterly ridiculous ticket_age_add thing is partially my fault, I suppose I should respond:
On Fri, May 19, 2017 at 4:10 PM Colm MacCárthaigh <c...@allcosts.net> wrote: > > And then separate to all of the above, and lower priority: >> > >> > * There's a contradiction between the obfuscated ticket age add >> parameter >> > and the desire to use tickets multiple times in other (non-0RTT) cases. >> We >> > can't do one without defeating the point of the other. Either remove the >> > obfuscation because it is misleading, or move it into an encrypted >> message >> > so that it is robust. >> >> The purpose of obfustication is not to hide sibling sessions. The >> client already blows its cover by using the same session ID twice. The >> purpose of obfustication is to hide the parent session. > > >> Are you talking about attackers being able to determine the rate of >> client clock? >> > > Right now if a ticket is used multiple times, then the ticket age can be > derived (trivial cryptanalysis due to re-using the same obfuscated offset, > and because the progression of time between the ticket uses is public); > that means the parent session can be identified. So the point is defeated. > Could you expand on your cryptanalysis? I don't believe this is actually leaked. It's addition mod 2^32, not XOR, which means you effectively randomize the parent starting time. (It was initially XOR, and then shortly changed to addition <https://www.ietf.org/mail-archive/web/tls/current/msg20376.html>.) Consider: initial connection at time t1, issues a ticket with ticket_age_add = x. Let t1' = t1 - x. Resumption 1 at time t2, offers t1's ticket. The attacker learns t2 - t1 + x = t2 - t1'. Resumption 2 (or HelloRetryRequest) at time t3, offers t1's ticket. The attacker learns t3 - t1 + x = t3 - t1'. x is uniformly distributed over [0, 2^32), so t1' = t1 - x is as well. This is a one-time pad on t1, correctly used only once. x is only ever used to encrypt one timestamp, t1. Of course, the attacker can correlate t2 and t3 by subtracting the two public values and checking against the public difference between connections they observe. But the ticket's already leaked anyway. > Either the one-time-pad can be used just one time (which means the ticket > can be used just once) or we should move it to an encrypted message. Or > just get rid of it and not be so misleading. But the current state is > weird, to say the least. > I believe stuffing something into an AEAD was proposed and then rejected by the cryptographers for some reason? You'd have to ask other folks for details. I just recall being told that was a previous rejected proposal. Accordingly, I suggested the dumbest thing that could possibly work, intending it be so dumb that it could not possibly have consequences beyond patching that correlation hole. :-) David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
