On Fri, Jul 30, 2021 at 05:21:25PM -0700, Christian Huitema wrote: > > On 7/30/2021 1:38 PM, Robert Evans wrote: > > On Fri, Jul 30, 2021 at 4:02 PM Christian Huitema <[email protected]> > > wrote: > > > > > I think we have a reasonable guideline here. 0-RTT for QUIC is so > > > compelling that clients and servers will still do it, even if we tell them > > > not to. So it is better to try provide usage guidelines on how to do that > > > safely. > > > > > > Robert's proposal fall in two categories: some are about embracing 0-RTT > > > in order to ensure good performance, like accepting early data and > > > ensuring a minimum lifetime of tickets. (With some nits -- you cannot set > > > the max_early_data_size to 512 bytes in QUIC, you have to use a QUIC > > > transport parameter instead.) Then, some of the recommendations are about > > > "try to keep it safe": > > > > > > 1) Do not accept a client hello that is older than 30 seconds. This would > > > limit the efficacy of the replay attacks, because it probably takes at > > > least 30 seconds to ensure that the cache is empty. But I am not too sure > > > how one tests the lifetime of a client Hello. > > > > > See > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8446*section-8.3__;Iw!!GjvTz_vk!FuZeymeFKUmTSm947f29K29rPi_MMwIRxbdCaDFCCXrRX-J4CThQ7Yx3aAvg4g$ > > . > > I see. The proposed mechanism uses the obfuscated_ticket_age, from which the > server can deduce the time at which the client sent the ClientHello. That's > a good check for cooperating clients, but I do not think that it was > designed to control replay attacks. The value is encoded by the client as > the sum of the age of the ticket in milliseconds and the ticket_age_add > parameter of the ticket. Attackers do not have access to the ticket_age_add > value, but they do not need to. They merely need to increment the > obfuscated_ticket_age by the delay in milliseconds between capture and > replay. I would not recommend relying on that mechanism as a defense against > cache probing attacks.
Wouldn't that break the PSK binder? -Ben _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
