Re: [dns-privacy] Benjamin Kaduk's No Objection on draft-ietf-dprive-bcp-op-10: (with COMMENT)

[Sara Dickinson <[e-mail]>]

Hi Ben, 

Thanks for both your responses and for updating the DISCUSS!

Best regards

Sara. 

> On 29 Jun 2020, at 17:47, Sara Dickinson <[e-mail]> wrote:
> 
> 
> 
>> On 28 Jun 2020, at 01:10, Benjamin Kaduk via Datatracker <[e-mail]> 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. 
> 
>> 
>> 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 “
> 
>> 
>> 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.
> 
>> 
>> 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.
> 
> 
>> 
>> 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:
> 
> "* 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/ 
> 
>> 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
> 
> 
> 
> Thanks
> 
> Sara. 
>