On Fri, May 19, 2017 at 4:49 PM, David Benjamin <david...@chromium.org> wrote:
> 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. :-) > What was rejected was actually having the stuffed Finished be an AEAD-encrypted block containing stuff like the ticket_age. We could certainly derive a new key and AEAD it if we wanted to, that just seemed like a lot more work than I think people wanted to do. -Ekr > > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
