Subject: [dns-privacy] I-D Action: draft-ietf-dprive-dnsoquic-06.txt

From: [email-masked]
Date: Wed, 20 Oct 2021 09:11:14 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS PRIVate Exchange WG of the IETF.

        Title           : DNS over Dedicated QUIC Connections
        Authors         : Christian Huitema
                          Sara Dickinson
                          Allison Mankin
	Filename        : draft-ietf-dprive-dnsoquic-06.txt
	Pages           : 30
	Date            : 2021-10-20

Abstract:
   This document describes the use of QUIC to provide transport privacy
   for DNS.  The encryption provided by QUIC has similar properties to
   that provided by TLS, while QUIC transport eliminates the head-of-
   line blocking issues inherent with TCP and provides more efficient
   packet loss recovery than UDP.  DNS over QUIC (DoQ) has privacy
   properties similar to DNS over TLS (DoT) specified in RFC7858, and
   latency characteristics similar to classic DNS over UDP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dprive-dnsoquic-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-dnsoquic-06

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 20 Oct 2021 17:17:44 +0100

Hi All, 

We are very grateful to several members of the QUIC WG (particularly Martin Thomson) for detailed feedback on the -05 draft presented for WGLC. Due to the number of changes this produced we wanted to publish a revised document at this stage to make subsequent review easier. There is still 1 week remaining of the WGLC. 

This -06 update includes the following changes:

* Many minor editorial improvements
* Add a new error code DOQ_EXCESSIVE_LOAD that can be used when too many requests are cancelled
* Reserve an error code for greasing
* Add text on connection migration
* Add text on privacy issues with long duration sessions
* Clean up some error handling corner cases
* Clarify text on re-playable transactions
* Clarify linkage to advice in RFC7766
* Improve text on DSO 
* Improve text on Message ID mappings
* Update all section references that point to other documents to link directly to that section
* Remove or move some outdated text from earlier discussions

Regards

Sara. 

> On 20 Oct 2021, at 17:11, [email-masked] wrote:
> 
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Oct 2021 23:16:45 +0000

After reading the -06 somewhat carefully, I have only one question: why should the DNS message ID be set to 0? If there's a good reason, is should be listed in Section 5.2.1, but if there isn't, the requirement should be removed. As the text indicates, this requirement makes forwarding more difficult. It also makes a special case for a client implementation that can do both DoQ and DoT.

--Paul Hoffman

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 21 Oct 2021 15:07:22 +0100

> On 21 Oct 2021, at 00:16, Paul Hoffman <[email-masked]> wrote:
> 

Hi Paul,

The stream mapping of DoQ allows for unambiguous correlation or queries and responses so the the message ID isn’t needed. Using 0 means the number of outstanding queries on a DoQ connection isn’t limited to the Message ID space which would be an artificial limit inherited from DNS-over-UPD/TCP. It seems wrong to impose that on a transport specifically designed to multiplex, just to make proxying simpler.  Given that RFC8484 says "DoH clients ... SHOULD use a DNS ID of 0 in every DNS request.” that proxy problem already exists and isn’t unique to DoQ. 

It’s presence would also change the error condition from ‘what if the message ID isn’t 0’ to 'what happens if the response ID on a stream doesn’t match the query ID?’. It’s marginal but the former feels slightly cleaner.

However, we can certainly add text to clarify this - I’ve opened https://github.com/huitema/dnsoquic/issues/125

Sara.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 21 Oct 2021 14:58:16 +0000

> The stream mapping of DoQ allows for unambiguous correlation or queries and responses so the the message ID isn’t needed. Using 0 means the number of outstanding queries on a DoQ connection isn’t l…

Arrrgh. I vaguely remembered that discussion. I forgot that we ended up with that in DoH, so it's OK if we end up with it in DoQ.

> It’s presence would also change the error condition from ‘what if the message ID isn’t 0’ to 'what happens if the response ID on a stream doesn’t match the query ID?’. It’s marginal but the former…

We disagree on which feels cleaner, but that's moot. My argument against always-0 (it differs from DoT) is trumped by it being the same as DoH. This is a hassle that implementers have already seen.

--Paul Hoffman

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 22 Oct 2021 02:27:38 +1100

On Fri, Oct 22, 2021, at 01:58, Paul Hoffman wrote:
> We disagree on which feels cleaner, but that's moot. My argument 
> against always-0 (it differs from DoT) is trumped by it being the same 
> as DoH. This is a hassle that implementers have already seen.

Another reason that might be relevant: when forwarding queries or responses, isn't it necessary to rewrite the message ID for any transport you use? If only to have control over collision risk.