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

From: [email-masked]
Date: Fri, 03 Sep 2021 09:33:07 -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           : Specification of DNS over Dedicated QUIC Connections
        Authors         : Christian Huitema
                          Sara Dickinson
                          Allison Mankin
	Filename        : draft-ietf-dprive-dnsoquic-04.txt
	Pages           : 28
	Date            : 2021-09-03

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
   error corrections 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-04

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

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

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 6 Sep 2021 09:00:16 +0100

Hi All, 

The 04 update to the DNS over QUIC draft includes the following changes:

* Updated text on repayable transactions, server behaviour when receiving 0-RTT data and session resumption
* Updated text on privacy issues with 0-RTT data and session resumption
* Updated recommendations on padding
* Updated text on flow control mechanisms
* Transaction Cancellation: Use of STOP_SENDING with new application error code DOQ_REQUEST_CANCELLATION allows clients to cancel queries
* Request to create a registry for DoQ error codes, following recommended practice
* Clarifying text on server initiated transactions

Regards

Sara. 

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

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 7 Sep 2021 14:22:23 -0400

I'm very excited for 0-RTT support in DoQ, but I don't think that text
(Section 9.1, Section 5.5) should be in this document.  The benefits and
risks associated with 0-RTT here have nothing to do with DoQ specifically;
they are the same in DoT and DoH.

This working group already has an adopted document with the sole purpose of
describing rules for safe use of 0-RTT [1].  I would like to see the text
on 0-RTT moved into that document, so the working group can provide
consistent guidance on the use of 0-RTT, regardless of transport.

--Ben Schwartz

[1] https://datatracker.ietf.org/doc/html/draft-ietf-dprive-early-data

On Mon, Sep 6, 2021 at 4:01 AM Sara Dickinson <[email-masked]> wrote:

> * Transaction Cancellation: Use of STOP_SENDING with new application error
> code DOQ_REQUEST_CANCELLATION allows clients to cancel queries

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 9 Sep 2021 12:14:14 +0100

Hi Ben, 

Thanks for the comment. When doing the last update there was a discussion between the authors about referencing that document, however we chose not to a for a few reasons:

* Whilst that work was adopted in April 2020, draft-ietf-dprive-early-data-00 expired in October 2020, and I can’t see any mailing list mentions of it after July time 2020
* It actually proposes a registry for RR types that can be used in early data which generated some discussion - the DoQ draft has a much simpler approach.  
* Also, DoQ does currently have a wider scope than DoT or DoH so it seemed helpful to address those specific scenarios in context. 

However, if the working group does want the guidance moved there then we probably need to look again at authors for that document so it can progress. And if it were to be a normative reference for DoQ the two would need to move forward together to avoid any delay to DoQ (which we are hoping will move to WGLC in the not too distant future). 

Sara. 

> On 7 Sep 2021, at 19:22, Ben Schwartz <[email-masked]> wrote:
> 
> I'm very excited for 0-RTT support in DoQ, but I don't think that text (Section 9.1, Section 5.5) should be in this document.  The benefits and risks associated with 0-RTT here have nothing to do with DoQ specifically; they are the same in DoT and DoH.
> 
> This working group already has an adopted document with the sole purpose of describing rules for safe use of 0-RTT [1].  I would like to see the text on 0-RTT moved into that document, so the working group can provide consistent guidance on the use of 0-RTT, regardless of transport.
> 
> --Ben Schwartz
>

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 9 Sep 2021 19:13:37 +0200

> However, if the working group does want the guidance moved there then we probably need to look again at authors for that document so it can progress. And if it were to be a normative reference for…

I personally can imagine just writing that 0-rtt guidance would come in 
a future RFC (and the reference would be the other way).

--Vladimir

---

From: Christian Huitema <[email-masked]>
Date: Thu, 9 Sep 2021 10:43:39 -0700

On 9/9/2021 10:13 AM, Vladimír Čunát wrote:

>> However, if the working group does want the guidance moved there then 
>> we probably need to look again at authors for that document so it can 
>> progress. And if it were to be a normative reference for DoQ the two 
>> would need to move forward together to avoid any delay to DoQ (which 
>> we are hoping will move to WGLC in the not too distant future).
>
> I personally can imagine just writing that 0-rtt guidance would come 
> in a future RFC (and the reference would be the other way). 

I think Sara expressed the practical issue well: in theory, it would be 
very nice to have all 0-RTT guidance in a single space, but in practice 
we did not see much progress in the development of such guidance. 
Support for 0-RTT is a pretty important feature for DNS over QUIC, so 
the practical solution for us was to write the guidance as part of the 
DNS over QUIC draft. This does not preclude writing a generic 0-RTT 
guidance later; that "guidance RFC" will simply have to "update section 
5 of [DoQ]." (There are slight differences in the engineering of 0-RTT 
in TLS and 0-RTT in QUIC, but I suppose these could be delineated in the 
guidance RFC.)

-- Christian Huitema

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 9 Sep 2021 13:49:26 -0400

On Thu, Sep 9, 2021 at 7:14 AM Sara Dickinson <[email-masked]> wrote:

> Hi Ben,
>
> Thanks for the comment. When doing the last update there was a discussion
> between the authors about referencing that document, however we chose not
> to a for a few reasons:
>
> * Whilst that work was adopted in April 2020,
> draft-ietf-dprive-early-data-00 expired in October 2020, and I can’t see
> any mailing list mentions of it after July time 2020
>

Yes.  I think we need to reactivate it, with new authors if necessary.

> * It actually proposes a registry for RR types that can be used in early
> data which generated some discussion - the DoQ draft has a much simpler
> approach.

Yes, I think the DoQ draft's approach is better.  However, the existence of
a conflict suggests a lack of working group consensus.  I think the
clearest way to resolve that conflict (and avoid discrepancies in the
treatment of 0-RTT between DoT and DoQ) is to update
draft-ietf-dprive-early-data.

---

From: Brian Haberman <[email-masked]>
Date: Fri, 10 Sep 2021 10:28:03 -0400

> Yes.  I think we need to reactivate it, with new authors if necessary.

People who are interested in the early-data draft should work with the
authors to revive the document and raise points of discussion with the WG.
> draft-ietf-dprive-early-data.

As noted above, I would encourage folks to engage with the early-data
draft authors. I do not see a reason to hold up the progression of the
DoQ draft at this point.

Regards,
Brian