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

[Benjamin Kaduk <[e-mail]>]

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