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

[Sara Dickinson <[e-mail]>]

> On 9 Mar 2022, at 17:41, Martin Duke via Datatracker <[e-mail]> wrote:
> 
> 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.

Hi Martin,

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:
> 
> "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.

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."

> 
> (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.

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

> 
> (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.

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

Best regards

Sara.