On 7/30/2021 1:38 PM, Robert Evans wrote:
On Fri, Jul 30, 2021 at 4:02 PM Christian Huitema <[email protected]>
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://datatracker.ietf.org/doc/html/rfc8446#section-8.3.
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.
The idea is the ticket age from the client in conjunction with the ticket
issuance time is used to estimate the age of the ClientHello. I have no
idea if there's an equivalent in QUIC-TLS.
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.
Single-use tickets, stateful replay protection, and limiting
session tickets to 30 seconds all bias against 0-RTT, hence we should draft
something which recommends avoiding all of those.
Single use tickets are not a problem if the ticket is renewed after use.
We are concerned with replay attacks, but in the case of a replay attack
the handshake does not conclude correctly. Renewing a ticket after the
handshakes concludes correctly should work in most cases. Note that we
are bound to recommend single use tickets anyhow, because the ticket is
a unique identifier of the client and reusing it enables tracking.
I understand your concern about limiting 0-RTT capability to a short
duration. I am just looking for alternatives that can easily be
implemented in multiple stacks. If something like the
obfuscated_ticket_age mechanism was robust against replays, it would
work. But as it is, I don't think it does.
In other words, I think we should try to design DoQ to allow and recommend
deploying 0-RTT such that almost all queries can use 0-RTT after first
contact except in the long-tail case where the resolver almost never sends
queries.
I agree with that goal. But I would like a mechanism by which servers
can reliably prevent replay attacks.
-- Christian Huitema
-- 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
<[email protected]> wrote:
I think this should be decided as part
ofhttps://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]>
<[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
[email protected]https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing
[email protected]https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing
[email protected]https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
