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

[Robert Evans <[e-mail]>]

DoQ plus 0-RTT seems very compelling for achieving 1-RTT query/response
parity with Do53.

As such I think the spec should discuss 0-RTT and encourage both clients
and servers to support it.

I also think a recommended 0-RTT profile suitable for DoQ/T should be
developed and specified.

For example (but I'm not a TLS expert, corrections welcome):
- self-contained, non-single-use tickets
- ticket_lifetime at least 6 hours
- early_data allowed
- max_early_data_size of 512 bytes
- implement replay protection by freshness check
- reject ClientHello with age over 30 seconds
- offer tickets only on full handshakes or if ticket is old
- send tickets as early as possible in the session
- allow resumption for any SNI offered in the server certificate
- no early data for mutating queries

No opinion as to which draft should contain those recommendations.

On Fri, Jul 30, 2021 at 10:53 AM Ben Schwartz <bemasc=
[e-mail]> wrote:

> I think this should be decided as part of
> https://datatracker.ietf.org/doc/html/draft-ietf-dprive-early-data, and
> DoQ should just reference it.  (I don't necessarily agree with the present
> contents of that draft.)
>
> As for what draft-ietf-dprive-early-data should say, I don't have a strong
> opinion.  However, I do think it's notable that most recursive resolvers
> allow "cache probing" by setting RD=0 in the query, which enables a
> relatively straightforward plaintext recovery attack on 0-RTT queries on
> multi-instance recursive resolvers.  An attacker can probe a cache instance
> until some records of interest fall out, then replay the 0-RTT query and
> repeat the probes to see if any of them reappear.  As such, I think it
> might be appropriate to strengthen the replay defense requirement for
> encrypted DNS beyond the "SHOULD" in RFC 8446.
>
> (See also https://github.com/tlswg/tls13-spec/issues/1225)
>
> On Thu, Jul 29, 2021 at 8:31 PM Christian Huitema <[e-mail]>
> wrote:
>
>> The DNS over QUIC draft lets client and server negotiate 0-RTT, with
>> minimal guidance. The privacy section develops the risks of replay
>> attacks, and then effectively lets clients decide whether to use 0-RTT
>> or not. Martin Thomson pointed out the contrast with RFC 8470 which
>> provides great details on the use of 0-RTT data in HTTP, and also
>> introduces a new error code to let server refuse some transactions if
>> received over 0-RTT. There are indeed advantages in letting the server
>> control usage of 0-RTT, but I wonder about the proper trade-off between
>> control and complexity for DoQ. There are multiple ways to do this:
>>
>> - Allow servers to not advertise support for 0-RTT if they are concerned
>> with 0-RTT side effects -- very simple to implement at servers and
>> clients.
>>
>> - Let servers advertise support for 0-RTT, but have them check the
>> queries received on 0-RTT and return an error code after inspecting
>> incoming requests. This requires implementing some kind of filter at the
>> server side, plus some logic on the client to resubmit the failed
>> requests after completion of the handshake. I am a bit concerned with
>> that kind of complexity.
>>
>> - Let servers advertise support for 0-RTT, but close the transaction
>> with a Protocol Error if the server receives an unexpected request --
>> e.g., an Update. That also requires some filtering of 0-RTT packets at
>> the server side, but is simpler than the full inspection considered
>> above. It is also reasonably easy to implement on the client, which
>> simply abstains to send some classes of requests over 0-RTT.
>>
>> - Or, of course, allow servers to support 0-RTT without any kind of
>> filtering.
>>
>> Any particular opinion in the working group?
>>
>> -- Christian Huitema
>>
>>
>>
>>
>> _______________________________________________
>> dns-privacy mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>