Subject: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-dnsoquic-10: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Wed, 09 Mar 2022 09:41:04 -0800

Martin Duke has entered the following ballot position for
draft-ietf-dprive-dnsoquic-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this draft! It was very easy to read.

(4.3) says:

"Using QUIC might allow a protocol to disguise its purpose from devices on the
network path using encryption and traffic analysis resistance techniques like
padding. This specification does not include any measures that are designed to
avoid such classification."

but then Sec 6.4 has a detailed, normative discussion of how to use padding to
avoid classification. I suggest you delete or edit the bit in 4.3.

(5.3.1) Clients are allowed to send STOP_SENDING and servers are allowed to
send RESET_STREAM. Servers sending STOP_SENDING break the connection. Given the
prescriptiveness of these rules, it's odd that you don't address clients
sending RESET_STREAM. IMO this should be allowed, but either way it should be
specified.

(6.5.4) and (9.4) I hesitate to write this, as Christian is as well aware as
anyone, but IMO QUIC address migration is not quite as privacy-destroying as
this draft suggests. RFC9000 has a number of normative requirements to reduce
linkability, and work is ongoing to reduce it further. Granted, no
anti-linkability mitigation is perfect, and if this is a primary goal of DoQ
it's OK to discourage migration as you've done here.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 22 Mar 2022 09:40:21 +0000

> On 9 Mar 2022, at 17:41, Martin Duke via Datatracker <[email-masked]> wrote:
> 

Hi Martin,

Many thanks for the comments - please see the updates in version -11 which was just published, which we hope address your comments.

> avoid classification. I suggest you delete or edit the bit in 4.3.

We’ve update the last sentence to be:
“This specification does not
 include any measures that are designed to avoid such classification --
 the padding mechanisms defined in {{padding}} are intended to obfuscate the specific
 records contained in DNS queries and responses, but not the fact that this is DNS traffic."

> sending RESET_STREAM. IMO this should be allowed, but either way it should be

We’ve added an additional paragraph at the end of this section to try to address this - please review.

> it's OK to discourage migration as you've done here.

As I think you discussed with Christian, the issue being addressed is actually about disclosing the client location to the server.

Best regards

Sara.

---

From: Martin Duke <[email-masked]>
Date: Sun, 27 Mar 2022 14:32:28 -0700

LGTM

On Tue, Mar 22, 2022 at 2:40 AM Sara Dickinson <[email-masked]> wrote:

> > Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> Many thanks for the comments - please see the updates in version -11 which
> was just published, which we hope address your comments.
>
> >
> > (4.3) says:
> >
> As I think you discussed with Christian, the issue being addressed is
> actually about disclosing the client location to the server.
>
> Best regards
>
> Sara.