Re: [dns-privacy] Benjamin Kaduk's Discuss on draft-ietf-dprive-bcp-op-08: (with DISCUSS and COMMENT)

[Sara Dickinson <[e-mail]>]

> On 27 Jun 2020, at 00:08, Benjamin Kaduk <[e-mail]> wrote:
> 
> Hi Sara,
> 
> My apologies as well that the response has taken so long.  (As Éric noted,
> this landed right as the COVID-19 craziness started, and I haven't fully
> recovered yet.)

Thanks Ben, yes the timing wasn’t great :-(  

Trimmed response below to address just the outstanding issues.

> 
>>> 
>>> [new discuss point]
>>> 
>>> This is perhaps more a flaw in RFC 8310 than in this document, but I'd still
>>> like to discuss it: in Section 5.1.2 we read that:
>>> 
>>>  When using DNS-over-TLS clients that select a 'Strict Privacy' usage
>>>  profile [RFC8310] (to mitigate the threat of active attack on the
>>>  client) require the ability to authenticate the DNS server.  To
>>>  enable this, DNS privacy services that offer DNS-over-TLS should
>>>  provide credentials in the form of either X.509 certificates
>>>  [RFC5280] or Subject Public Key Info (SPKI) pin sets [RFC8310].
>>> 
>>> Authenticating the DoT server via X.509 certificate as described here and in
>>> RFC 8310 seesm to involve looking for an ADN in the certificate; however, I
>>> could not find any discussion of how to know what CA(s) or trust anchors to
>>> trust to certify the ADN in a certificate.  It's possible that RFC 8310's
>>> use of "PKIX Certificate" is supposed to imply that Web PKI trust anchors
>>> are used, but that's not immediately clear.  
>> 
>> Yes - that was the intention. Nothing beyond that was proposed relating to DoT authentication. 
>> 
>>> It may be the case that we need
>>> to mention provisioning a trust anchor as well as the X.509 certificate
>>> information, here.
>> 
>> I don’t believe so. If you think some clarify text would help though, please do suggest what you would like to see.
> 
> Perhaps
> 
> OLD:
>                                                        To enable this,
>   DNS privacy services that offer DNS-over-TLS need to provide
>   credentials in the form of either X.509 certificates [RFC5280] or
>   Subject Public Key Info (SPKI) pin sets [RFC8310].
> 
> NEW:
>                                                        To enable this,
>   DNS privacy services that offer DNS-over-TLS need to provide
>   credentials that will be accepted by the client's trust model, in the
>   form of either X.509 certificates [RFC5280] or Subject Public Key
>   Info (SPKI) pin sets [RFC8310].

Agreed.

> 
> (Also, is use of DANE acceptable?)

Yes it is - it is covered in Section 8.2 of RFC8310.

> 
>>> 
>>>     outlining their operational practices and commitments with regard
>>>     to privacy thereby providing a means for clients to evaluate the
>>>     privacy properties of a given DNS privacy service.  In particular,
>>> 
>>> nit: *claimed* privacy properties.  (Absent an enforcement mechanism to
>>> ensure that the actual practices match the documentation, as Section 6.3
>>> alludes to.)
>> 
>> So, a few practices (mainly the protocol related ones) can be observed via testing e.g.
>> https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/
>> so suggest:
>> “evaluate the measurable and claimed privacy properties "
> 
> Okay.  If I try hard, I might convince myself that this "and" could be misread
> as an intersection, not a union, so maybe "evaluate both the measurable
> and the claimed”?

Sure.

>> 
>>> 
>>> Section 3
>>> 
>>> I'm not even sure that classifying as "increase"/"decrease" is accruate; my
>>> take would be that the protocol changes present a different profile of
>>> privacy-related properties that can increase or decrease privacy on many
>>> different axes simultaneously.
>> 
>> I do agree it is somewhat complex, but the contents of the Appendix are split into those two rough categories, with the decreases related to increased tracking and logging. Again, happy to add a reference to draft-ietf-dprive-rfc7626-bis, which tries to provide the more nuanced discussions. 
> 
> I think what bothers me is that even for a single individual change,
> whether it presents an increase or decrease in the privacy properties of
> the DNS can be a matter of debate, depending on which axis of privacy is
> weighted more strongly by the observer.  So maybe adding "in various
> ways" at the end of the sentence would reflect the potential nuance?

Agreed.

>> 
>>> 
>>>  We describe two classes of threats:
>>> 
>>> (side note: it might be an interesting exercise to analyze the "DNS Privacy
>>> Threats" to see which of them actually just reflect omissions in the 6973
>>> prifacy model vs. DNS-specific threats)
>>> 
>>>  This document does not specify policy - only best practice, however
>>>  for DNS Privacy services to be considered compliant with these best
>>>  practice guidelines they SHOULD implement (where appropriate) all:
>>> 
>>> This normative "SHOULD" feels weird, as it in some sense is giving me
>>> license to claim compliance when I do none of the listed things ("because
>>> it's only a 'SHOULD'").  Perhaps just saying that we define the three levels
>>> of compliance (with no normative language) is enough.
>> 
>> There were several discussions in the WG about this. The first version of the document used normative language throughout which many though wasn’t appropriate. A suggestion to remove normative language completely was felt to leave the document somewhat toothless so this compromise of using the single SHOULD and 3 levels of compliance was reached….
> 
> Replying here instead of the other AD ballot thread, for convenience...
> there is new text:
> 
>   In other words, these requirements are specified here as all being
>   normative requirements, and are classified only by different levels
>   of compliance in the rest of the document.
> 
> which still leaves me a little confused.  If they are all normative
> requirements, what makes the minimally/moderately/maximally compliant
> variations different?  Would the meaning change if, instead of the last
> clause we had a standalone sentence "The rest of this document refers
> only to the "threat mitigations", "optimizations", and "additional
> options", which correspond to the named levels of compliance stated
> above, but compliance (to the indicated level) remains a normative
> requirement”?

I think your proposed text is clearer than the current text. With a couple of tweaks would having the end of that section read as below work? 

“This document does not specify policy - only best practice, however for DNS
Privacy services to be considered compliant with these best practice guidelines
they SHOULD implement (where appropriate) all:

* Threat mitigations to be minimally compliant.
* Optimizations to be moderately compliant.
* Additional options to be maximally compliant.

The rest of this document does not use normative language but instead refers only
to the three differing classes of action which correspond to the three named
levels of compliance stated above. However, compliance (to the indicated level)
remains a normative requirement."


>>> 
>>>  It is also noted that DNS privacy service might be provided over
>>>  IPSec, DNSCrypt, or VPNs.  However, use of these transports for DNS
>>>  are not standardized and any discussion of best practice for
>>>  providing such a service is out of scope for this document.
>>> 
>>> I don't think it's quite correct to say that usage of IPsec to provide
>>> transport for DNS is "not standardized": you merely configure IPsec to
>>> protect communications to the IP address(es) that you configure as your
>>> resolver, and gain the protection of IPsec.  No DNS-layer protocol or
>>> configuration changes are needed, though you do tend to need some kind of
>>> prior configuration/agreement with the DNS server.
>> 
>> s/are standadized/are standardized in DNS specific RFCs/?
> 
> I'd consider avoiding the "standardized" word at all in favor of
> something like "there are not specific RFCs that cover use of these
> transports for DNS", though your proposal is an improvement over the
> previous state.

Your proposed text is clearer - will use that. 

> 
>>> 
>>> Section 5.3.1
>>> 
>>>  Optimizations:
>>> 
>>>  o  The server should either:
>>> 
>>>     *  not use the ECS option in upstream queries at all, or
>>> 
>>>     *  offer alternative services, one that sends ECS and one that
>>>        does not.
>>> 
>>> I'm not sure I understand the apparent recommendation to prefer no ECS at
>>> all to ECS with a limited prefix length.  Is there a pointer handy to the WG
>>> discussions?
>> 
>> I think the main point here is that ideally the service should offer the user the option to not use ECS at all because it does have recognised issues (and to do so at the service level since not many clients support the protocol defined opt-out). For example from Section 2 of that RFC7871: 
>> 
>> “We recommend that the feature be turned off by default in all
>>   nameserver software, and that operators only enable it explicitly in
>>   those circumstances where it provides a clear benefit for their
>>   clients. We also encourage the deployment of means to allow users to
>>   make use of the opt-out provided."
>> 
>>> 
>>>  If operators do offer a service that sends the ECS options upstream
>>>  they should use the shortest prefix that is operationally feasible
>>>  and ideally use a policy of whitelisting upstream servers to send ECS
>>>  to in order to minimize data leakage.  Operators should make clear in
>>>  any policy statement what prefix length they actually send and the
>>>  specific policy used.
>>> 
>>> I'll note that whitelisting is still subject to attack in the face of an RFC
>>> 3552 attacker unless the recursive/authoritative path is also secured and
>>> the authoritative authenticated (whether by DNSSEC on the responses or a
>>> transport-layer mechanism); this is probably worth discussion a little bit.
>> 
>> The text does just say ‘minimizes data leakage’ so I think it is clear it is only a partial solution and that any use of ECS carries a privacy risk?
> 
> Sometimes people autocomplete "minimizes" to "minimizes to zero" :)
> I wonder if "reduce" would work.

Yes - will replace. 

Sara.