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

[Colm MacCárthaigh <[e-mail]>]

On Fri, May 19, 2017 at 11:40 AM, Ilari Liusvaara <[e-mail]>
wrote:

> > * In order to fully reason about when that message may later get
> received,
> > there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by
> all
> > potential middle-boxes in the pipe that may be using 0-RTT.
>
> Isn't that potentially multi-party problem if middleboxes are involved?
>

Yes; but if we can agree on a hard maximum time-window for the 0RTT
section, and all of the parties agree, it's possible for a careful client
to negotiate its way around it. Even if it's 10 seconds, this still has
some value I think.


> > 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.

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.

-- 
Colm