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

[Eric Rescorla <[e-mail]>]

On Fri, May 19, 2017 at 4:49 PM, David Benjamin <[e-mail]>
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 <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>