Re: [dns-privacy] Use of 0-RTT in DNS over QUIC

[Christian Huitema <[e-mail]>]

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<[e-mail]>
>>> 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