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

[Christian Huitema <[e-mail]>]

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=
> [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
>>
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy