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.
2) Implement replay protection is a good idea. Some server deployments
support that. But I understand that this kind of support ends up
enforcing "only once" use of tickets. This contradicts the request for
non-single-use tickets, or the request to "offer tickets only on full
handshakes or if ticket is old".
Some QUIC stack will disable 0-RTT if the ticket is older than 30
seconds, only allowing resumption. This is reasonably easy to implement.
-- Christian Huitema
On 7/30/2021 8:56 AM, Robert Evans wrote:
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=
[email protected]> 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 <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
