LGTM On Tue, Mar 22, 2022 at 2:40 AM Sara Dickinson <[email protected]> wrote:
> > > > 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
