> On May 2, 2017, at 9:45 PM, Colm MacCárthaigh <c...@allcosts.net> wrote:
>
> I think we have to assume that a replay attempt could come at any time.
> A time based mitigation doesn't work.
A time-based mitigation does not remove the need for an anti-replay
cache (where a service protocol, supports 0-RTT, but is not idempotent).
What I am saying, is that a time-based counter-measure can substantially
reduce the size of the required cache, because out-of-window replays
are rejected. That replay window can be a narrow window around the time
the ticket is first (and never again legitimately) used, rather than the
much larger ticket validity interval.
The obfuscated_ticket_age field makes it possible to determine which
transmissions are "in-window". It remains an exercise for the implementor
to handle "in-window" replays appropriately.
I agree with Nico that additive obfuscation feels like a hack, but am
willing to accept this as somewhat "natural" within the design tradition
of TLS.
Could someone explain how observing ticket reuse reveals the secret
"ticket_age_add" value? The situation seems "time translation
invariant" under changes in the "ticket_age_add" value. Doesn't the
attacker see the same result as he would see with a for an offset
"ticket_age_add" obtained at a corresponding offset time in the past?
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
