> On 9 Mar 2022, at 17:41, Martin Duke via Datatracker <[email protected]> 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.
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
