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
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
