(inline)
On Mon, Jun 29, 2020 at 05:47:23PM +0100, Sara Dickinson wrote:
>
>
> > On 28 Jun 2020, at 01:10, Benjamin Kaduk via Datatracker <[email protected]>
> > wrote:
> >
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-dprive-bcp-op-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/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Thank you for the updates, including those that resolve my Discuss points.
> > I do have several new comments on the -10.
>
> Many thanks for the detailed review of -10.
>
> >
> > [note that I did not attempt to repeat comments made at
> > https://mailarchive.ietf.org/arch/msg/dns-privacy/bOK3mcSn-79wrAsawRQONBOZGGI/
> > ]
> >
> > Section 1
> >
> > Whilst protocols that encrypt DNS messages on the wire provide
> > protection against certain attacks, the resolver operator still has
> > (in principle) full visibility of the query data and transport
> > identifiers for each user. Therefore, a trust relationship exists.
> >
> > I commented previously about the strained nature of this conclusion, and
> > part of the response to that comment included a statement that "this
> > text is from the original RFC 7626". However, I don't see any sign of
> > this statement in RFC 7626 (and, per google, any other RFC), so perhaps
> > the reluctance to update at this stage is misplaced.
>
> You are quite right - my apologies - this text was in the very first draft of
> the BCP and is not in RFC7626!
>
> You previously proposed
> “Therefore, a trust relationship (whether explicit or implicit) is assumed to
> exist
> between each user and the operator of the resolver(s) used by that user.”
>
> which seems reasonable. Will update.
Thank you!
> >
> > Section 5.1.3.2
> >
> > Is (HTTP/2, EDNS(0)) padding a privacy threat or a mitigation?
>
> Good catch - bullet added to the wrong list in -10! Fixed.
>
> >
> > Section 5.2.1
> >
> > The following are recommendations relating to common activities for
> > DNS service operators and in all cases such activities should be
> > minimized or completely avoided if possible for DNS privacy services.
> >
> > Are the "such activities" that should be avoided the "common activities"
> > that we're giving recommendations for?
>
> Suggest: “and in all cases data retention should be minimized or completely
> avoided “
That matches what I expected; thanks
> >
> > Section 5.2.4
> >
> > nit: comma before "e.g." (as well as after)
> >
> > Section 5.3.1
> >
> > operator is happy with. However some operators consider allowlisting
> > to incur significant operational overhead compared to dynamic
> > detection of ECS on authoritative servers.
> >
> > nit(?): is this "detection of ECS support”?
>
> Both fixed.
>
> >
> > Section 6.1.2
> >
> > Should we mention the DoH URI template (if any) here, as well as the
> > address+port combos, DoT authentication domain name/SPKI/etc.?
> >
> > 2. Client facing capabilities. With reference to Section 5 provide
> > specific details of which capabilities are provided on which
> > client facing addresses and ports:
>
> > Is perhaps Section 5.1 a better reference than all of Section 5 here?
>
> I see the ambiguity (and the outdated section reference after a renumber). I
> think this should read:
>
> "With reference to each subsection of Section 5.1 provide specific details of
> which capabilities (transport, DNSSEC, padding, etc.) are provided on which
> client facing address/port combination or DoH URI template. For Section
> 5.1.2, clearly state which specific authentication mechanisms are supported
> for each endpoint that offers DoT:
>
> * The authentication domain name to be used (if any).
> * The SPKI pin sets to be used (if any) and policy for rolling keys.”
>
>
> IIRC the bullets were added just for clarity as none, one or both mechanisms
> might be used by a particular end point.
The bullets always seemed reasonable to me, and I think your "this should
read" looks good. Thanks!
> >
> > Section 8
> >
> > We should probably link to the security considerations sections of
> > DoT+DoH as well as RFC 7766. Arguably, those for DNSSEC as well.
>
> Yes - I’ll add.
>
> >
> > Section 12.1
> >
> > It's not immediately clear that RFC 8404 needs to be a normative
> > reference (it's cited for the DNS Privacy Threat that "increased use of
> > encryption can impact [...] operator ability to monitor traffic" but
> > that's just an informative notice and does not really give specific
> > implementation advice to adhere to.
> >
> > Section 12.2
> >
> > The way in which we cite RFC 7457 seems to be incorporating it by
> > reference, which would arguably make it a normative reference.
> >
> > RFC 7706 should also be normative, since we have a recommended behavior
> > for running root on loopback.
> >
> > Likewise we mandate/recommend behavior from RFCs 7871, 8020, 8198, and
> > 8490, making them normative.
>
> Done.
>
>
> >
> > Appendix A.2
> >
> > o Section 8 of [RFC8484] outlines the privacy considerations of DoH.
> > Note that depending on the specifics of a DoH implementation there
> > may be increased identification and tracking compared to other DNS
> > transports.
> >
> > I would suggest noting that this document recommends against the use of
> > these mechanisms that might lead to increased identification/tracking.
>
> Done.
>
> >
> > Appendix B
> >
> > nit: s/Pseudoanonymization/Pseudonymization/
> >
> > use of a format-preserving technique is essential. This, though, is
> > not cost-free - several authors (e.g., [Brenker-and-Arnes] have
> > observed that, as the entropy in an IPv4 address is limited, given a
> > de-identified log from a target, if an attacker is capable of
> > ensuring packets are captured by the target and the attacker can send
> > forged traffic with arbitrary source and destination addresses to
> > that target, any format-preserving pseudonymization is vulnerable to
> > an attack along the lines of a cryptographic chosen plaintext attack.
> >
> > nit(?): the way this is written ("given a de-identified log from a
> > target") makes it sound like the log is obtained first, and then
> > afterward (new) traffic with known addresses is generated (i.e., not in
> > the initial log), and somehow this allows for the deanonymization. My
> > understanding was that the known traffic needed to be part of the log
> > being deanonymized, i.e., the causality reversed from my above
> > description.
>
> Suggest:
>
> "This, though, is not cost-free - several authors (e.g., [Brenker-and-Arnes]
> have
> observed that, as the entropy in an IPv4 address is limited, if an attacker
> can
> * ensure packets are captured by the target and
> * send forged traffic with arbitrary source and destination addresses to that
> target and
> * obtain a de-identified log of said traffic from that target
> any format-preserving pseudonymization is vulnerable to an attack along the
> lines of a cryptographic chosen plaintext attack.
That works for me, thanks again.
>
> >
> > Appendix B.1
> >
> > o Filtering. Removing (and thus truncating) or replacing data in a
> > field. Field data can be overwritten, often with zeros, either
> > partially (grey marking) or completely (black marking).
> >
> > Is there a reference for grey/black marking? If they are not in common
> > use, perhaps there is not additional value from mentioning these names.
>
> The term 'black-marker anonymization’ is used throughout RFC6235 (which is
> the basis of this categorisation) and in other sources but I don’t see
> grey-marker used there and I’m struggling to remember where it came from…
> Re-reading RFC6235 I think ’truncation’ is more correct:
Ah, I hadn't pulled up 6235.
>
> "* Filtering. Removing or replacing data in a field. Field
> data can be overwritten, often with zeros, either partially (truncation
> or reverse truncation) or
> completely (black-marker anonymization)."
>
> and later in the section s/grey marking/truncation/
Sure.
> > Section D.1
> >
> > There may be some privacy relevance to the precision of timestamp used
> > for the various (logging) operations, relating to (e.g.) recorrelation
> > with external datasets.
> >
>
> Suggest:
>
> OLD:
> + Absolute arrival time
>
> NEW:
> + Absolute arrival time using a precision of ms
Okay, thanks. The reader will have to do their own analysis of what kind
of recorrelation ms precision admits, but that seems unavoiadable in some
sense; what's important is that the reader has enough information to do so.
Thanks for the updates,
Ben
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
