Subject: [dns-privacy] DPRIVE WGLC : https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/

From: Brian Haberman <[email-masked]>
Date: Wed, 13 Oct 2021 07:30:47 -0400

DPRIVE & QUIC WG Participants,

      This starts a 2-week DPRIVE WG Last Call for advancing 
draft-ietf-dprive-dnsoquic-05 as a Proposed Standard. Please send all 
substantive comments to the DPRIVE mailing list. Editorial comments 
should be directed to the document editors. This last call will end 
11:59pm UTC on Oct. 27, 2021.

Regards,
Brian & Tim

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 15 Oct 2021 13:38:48 +1100

I've reviewed this document (straight from GitHub in this case).

I've opened a few issues:  https://github.com/huitema/dnsoquic/issues/created_by/martinthomson

You will observe that some of these issues are old and remain unaddressed.  It is my opinion that the document is not ready and it needs another pass to improve a number of problems.

To be clear, I think that the core protocol definition is good.  

I found a large number of editorial issues when I was reviewing it.  I provided pull requests for some, but there are a great many more that would benefit from a careful proof read and cleanup.  Martin Duke found several issues to add to this; those also need to be addressed.

However, there are a number of substantive problems in the supporting material that I think need to be fixed.  For instance, some of these are false or misleading claims about security properties.  There are enough of these that I don't think that this document is fit to give to the IESG.  I don't think that any of these are hard to address, but there are rather a lot of them.

Regards,
Martin

On Wed, Oct 13, 2021, at 22:30, Brian Haberman wrote:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
> Attachments:
> * OpenPGP_signature

---

From: Christian Huitema <[email-masked]>
Date: Fri, 15 Oct 2021 11:51:00 -0700

As Martin mentions, we had a number of issues opened recently in the 
GitHub repo managed by the authors 
(https://github.com/huitema/dnsoquic/). A lot of them have been opened 
after reviews by members of the QUIC working group. We have a bit of a 
culture clash here. The QUIC WG used GitHub intensely, but DPRIVE is 
usually more cautious, using it for coordination between the authors of 
the draft and possibly for straightforward editorial issues. here is a 
short list of the issues that are definitely not editorial:

* Error code extensibility, and greasing of error codes. Several QUIC 
frames carry application defined error codes: reset stream, stop sending 
and close connection. The draft specifies a small set of error codes to 
use with these frames, and also specifies an extension mechanism to 
register more error codes. Issues 
https://github.com/huitema/dnsoquic/issues/80 and 
https://github.com/huitema/dnsoquic/issues/81, by Lucas Pardue, request 
to specify that receiving an "unknown" error code is not an error, and 
suggest that implementations can test the extensibility mechanism by 
sometimes sending different error codes, a.k.a., greasing. Proposed 
resolution in https://github.com/huitema/dnsoquic/pull/108.

* Request to specify what happens if a node receives data in unexpected 
QUIC streams, issue https://github.com/huitema/dnsoquic/issues/82 by 
Lucas Pardue. DoQ only uses bidirectional QUIC streams opened by the 
client when sending a query, but QUIC permits other type of streams, 
such as unidirectional streams opened by the client or the server, or 
bidirectional streams open by the server. The spec did not specify how 
to handle data received in such streams. The proposed resolution is to 
treat that as a protocol error.

* Getting rid of the text about not deliberately avoiding middle-boxes, 
issue https://github.com/huitema/dnsoquic/issues/90 by Martin Thomson. 
While the text is correct, it does not discuss potential usage of SNI 
encryption or Encrypted Client Hello (ECH), both of which can be used to 
"armor" a TLS based protocol and make it harder to block by 
middle-boxes. Adding a discussion of such mechanism is likely to be 
contentious. The discussion of middle-boxes in section 4.3. is not 
essential in the document, and the simplest solution is to just remove it.

* Clarifying what happens if the client sends a query on a stream but 
fails to close the stream, issue 
https://github.com/huitema/dnsoquic/issues/93 by Martin Thomson. The 
draft specifies that adding a new query after the first one is an error, 
but is silent about failure to close the stream. Waiting for a proposed 
resolution.

* Details on connection closure and client abandoning connections before 
the idle timeout elapses, issue 
https://github.com/huitema/dnsoquic/issues/98. Proposed resolution is 
that the client can always "walk away", and to only require explicitly 
clsoing the connection if transactions are pending.

* Details on usage of 0-RTT with XFR QUERY, issue 
https://github.com/huitema/dnsoquic/issues/99 by Martin Thomson. The 
current text is wrong, because 0-RTT resumption includes carry over of 
the authentication negotiated in the previous connection. We may want to 
not consider XFR Queries as replayable, and ask servers to wait until 
the handshake is complete before processing them.

* Details on the 0-RTT mitigation text, issue 
https://github.com/huitema/dnsoquic/issues/102 by Martin Thomson. The 
current text is based on the original analysis done by DKG years ago, 
which pointed out the risks of replaying 0-RTT packets at attacker 
chosen times. That attack is largely mitigated by the replay protection 
in TLS 1.3, which is mandatory to implement. 0-RTT packets can only be 
replayed within a narrow window, which is only wide enough to account 
for variations in clock skew and network transmission.Need to update the 
text and account for that.

* Comparison of privacy effects of long duration session and session 
resumption, issue https://github.com/huitema/dnsoquic/issues/103 by 
Martin Thomson. If the client address did not change, session resumption 
and long duration sessions have similar effects on client privacy, and 
the text needs to reflect that.

DPRIVE members may want to discuss these issues on the mailing list.

-- Christian Huitema

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 15 Oct 2021 16:48:11 -0400

> text and account for that.

This seems like another good reason to move the 0-RTT discussion into the
0-RTT draft.  I've opened a copy-and-paste PR here:
https://github.com/ghedo/draft-ghedini-dprive-early-data/pull/4

I would appreciate clearer guidance from the chairs on where the 0-RTT text
should live.

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 16 Oct 2021 18:27:51 -0400

Christian

Thanks for bringing this up.  I make it a point to follow/receive updates
on all the repos of dprive documents, but I missed your repository.   The
chairs are advocates for using repositories like github for documents, as
we feel they have positive effects.

I believe the chairs have said this before, but it bears repeating: Please
feel free to use github for issue tracking,  especially those involving
editorial discussions.  But those issues raised which involve normative
changes to the document itself should be brought to the working group
mailing list for wider discussion and consensus.

I have not read all the issues Martin has raised, but those that look
substantial (such as 0-RTT) should be brought to the list. I suggest
starting separate email threads for each issue, to work through them
individually.

thanks
tim

On Fri, Oct 15, 2021 at 2:51 PM Christian Huitema <[email-masked]>
wrote:

> > I've opened a few issues:
> https://github.com/huitema/dnsoquic/issues/created_by/martinthomson
> >
> > You will observe that some of these issues are old and remain
> unaddressed.  It is my opinion that the document is not ready and it needs
> another pass to improve a number of problems.
> >
> > I found a large number of editorial issues when I was reviewing it.  I
> provided pull requests for some, but there are a great many more that would
> benefit from a careful proof read and cleanup.  Martin Duke found several
> issues to add to this; those also need to be addressed.
> >
> > However, there are a number of substantive problems in the supporting
> material that I think need to be fixed.  For instance, some of these are
> false or misleading claims about security properties.  There are enough of
> these that I don't think that this document is fit to give to the IESG.  I
> don't think that any of these are hard to address, but there are rather a
> lot of them.
> >
> > Regards,
> > Martin
> >

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 16 Oct 2021 18:30:24 -0400

This is a good point Ben. I'll catch up with Brian and discuss, but I'd
also like to hear from the working group and DNS-over-QUIC authors where
they feel this should live.

tim

On Fri, Oct 15, 2021 at 4:49 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

> I would appreciate clearer guidance from the chairs on where the 0-RTT
> text should live.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 18 Oct 2021 16:58:42 -0400

Agreed that we need input from the WG on this... especially if there is 
consensus that the DoQ draft needs to wait on the early-data draft.

Regards,
Brian

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 19 Oct 2021 10:38:36 +0100

All, 

On the topic of moving 0-RTT text to the early data draft, I still agree with Christian’s position from a couple weeks ago. I don’t think separating that text makes the DoQ draft easier to read or implement and it could significantly delay the progress of DoQ. I think we have made good progress during WGLC via the Github issues to providing the right guidance within the DoQ draft.

I support work on a separate 0-RTT draft to cover the wider set of issues with early data including details regarding other transports.

Regards

Sara. 

> On 18 Oct 2021, at 21:58, Brian Haberman <[email-masked]> wrote:
> 
> Signed PGP part
> Agreed that we need input from the WG on this... especially if there is consensus that the DoQ draft needs to wait on the early-data draft.
> 
> Regards,
> Brian
>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 19 Oct 2021 09:14:42 -0400

I do think the DoQ draft is harder to read because of the 0-RTT text, which
is spread across several sections.

I don't see why the DoQ draft would be blocked by the Early Data draft,
seeing as RFC 7858 was not blocked.

On Tue, Oct 19, 2021 at 5:39 AM Sara Dickinson <[email-masked]> wrote:

> All,
>
> On the topic of moving 0-RTT text to the early data draft, I still agree
> with Christian’s position from a couple weeks ago. I don’t think separating
> that text makes the DoQ draft easier to read or implement and it could
> significantly delay the progress of DoQ. I think we have made good progress
> during WGLC via the Github issues to providing the right guidance within
> the DoQ draft.
>
> I support work on a separate 0-RTT draft to cover the wider set of issues
> with early data including details regarding other transports.
>
> Regards
>
> Sara.
>
> >>> On Fri, Oct 15, 2021 at 2:51 PM Christian Huitema <[email-masked]
> >
> >>> wrote:
> >>>

---

From: Brian Haberman <[email-masked]>
Date: Tue, 19 Oct 2021 17:16:39 -0400

Hi Ben,

> seeing as RFC 7858 was not blocked.

I am not sure how RFC 7858 is relevant. It was published 4 years before 
the 0-RTT draft came into existence.

Are you suggesting that DoQ should not mention anything about 0-RTT?

Regards,
Brian

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 19 Oct 2021 17:28:05 -0400

> Are you suggesting that DoQ should not mention anything about 0-RTT?

Saying literally nothing might be a bit too much, but I think it can
essentially defer the issue or reference another draft.

I don't think DoQ deployment is being delayed by lack of an RFC number.  If
the draft ends up in the REF state for a while due to an unpublished
dependency, I don't think that's a problem.

I do think the current document structure, with 0-RTT text spread across at
least three different sections, is much harder to read than if it were
separated.

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 20 Oct 2021 14:21:40 +0100

> On 19 Oct 2021, at 22:28, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 
> On Tue, Oct 19, 2021 at 5:16 PM Brian Haberman <[email-masked]> wrote:
> Hi Ben,
> 
> Saying literally nothing might be a bit too much, but I think it can essentially defer the issue or reference another draft.
> 
> I don't think DoQ deployment is being delayed by lack of an RFC number.  If the draft ends up in the REF state for a while due to an unpublished dependency, I don't think that's a problem.

Christian pointed out that the usefulness of 0-RTT is such that implementors will be keen to test and use it as soon as they deploy DoQ, so I think there is significant value in both including it in the document, and not holding up the publication of the RFC. Given that DoQ is in WGLC and the early-data draft is not even officially resurrected from expiry yet, it could be 1 or more years behind DoQ. That uncertainty is something we can avoid.

Many organisations (enterprises, policy bodies, etc.) don’t appreciate the multiple stages of review prior to publication and do take meaning from the RFC being published.

Sara.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Oct 2021 14:55:11 +0000

As someone who doesn't pretend to understand the intricacies of Quic, and who wants to see DoQ deployed:

Is the issue here the organization of the  0RTT/early-data material in draft-ietf-dprive-dnsoquic, or that the material is wrong or materially insufficient?

If it is the former, it would make sense for the authors to reorganize the draft and we have a second WG Last Call. If it is the latter, it sounds like the draft should be reorganized anyway so that it is easier for the critics to say what is wrong or not yet covered.

--Paul Hoffman

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 20 Oct 2021 16:37:12 +0100

> On 20 Oct 2021, at 15:55, Paul Hoffman <[email-masked]> wrote:
> 

Paul, 

If you read the draft you will see it is the bulk the text is in 2 sections: a ’Specification’ section and an ‘Implementation requirements’ section and 0-RTT is covered in both. The topic is also mentioned in the Privacy Considerations section, so while it is mentioned in 3 places, it is in context. 

We’ve had some quite detailed review, particularly during WGLC, and we have no outstanding issues relating to the 0-RTT text at the moment, other than Ben’s suggestion to split it out. So I don’t believe the issue is with the content of that text. We’ll be putting out an -06 shortly (before the end of WGLC) and would appreciate further specific review of the text in that. 

Best regards

Sara.

---

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

> If you read the draft you will see it is the bulk the text is in 2 sections: a ’Specification’ section and an ‘Implementation requirements’ section and 0-RTT is covered in both. The topic is also m…

I apologize for doing what I really dislike other people doing: writing about a draft I have not read in a long time. I have now read -06 with an eye towards 0-RTT, and completely agree with you that the implementation requirements and suggestions are clear. A developer should have no problem finding them in the document even though they are in three places because those three places are well-labeled.

--Paul Hoffman

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 21 Oct 2021 10:20:01 +1100

On Thu, Oct 21, 2021, at 10:12, Paul Hoffman wrote:
> I apologize for doing what I really dislike other people doing: writing 
> about a draft I have not read in a long time. I have now read -06 with 
> an eye towards 0-RTT, and completely agree with you that the 
> implementation requirements and suggestions are clear. A developer 
> should have no problem finding them in the document even though they 
> are in three places because those three places are well-labeled.

Having been more closely involved in improving this text, I agree with Paul.  This is useful text.

I think that Ben's push here is a laudable attempt to reduce duplication of text, particularly with the view of providing a canonical reference for early data in DNS.  However, I would prefer some duplication over a less than complete DoQ specification.