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