On 7/30/2021 5:33 PM, Benjamin Kaduk wrote:
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.
Seehttps://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?
Yes it would, of course. And that would indeed prevent replaying the
0-RTT data. I was wrong.
-- Christian Huitema
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
