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

[Martin Duke <[e-mail]>]

LGTM

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

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