Re: [Gen-art] [dns-privacy] Genart last call review of draft-ietf-dprive-bcp-op-07

[Eric Rescorla <[e-mail]>]

On Mon, Feb 10, 2020 at 11:44 AM Mohit Sethi M <[e-mail]>
wrote:

>
> On 2/10/20 9:18 PM, Eric Rescorla wrote:
>
>
>
> On Mon, Feb 10, 2020 at 8:14 AM Mohit Sethi M <mohit.m.sethi=
> [e-mail]> wrote:
>
>> Hi Sara,
>>
>> I understand the desire to get this done with. However, I have some
>> further comments in-line:
>> On 1/24/20 5:29 PM, Sara Dickinson wrote:
>>
>> Mohit,
>>
>> I’m out of the office next week so in order to try to move the draft
>> along I have published an -08 version which I think addresses most of your
>> comments (there were a few questions in my response below). Please let me
>> know if any are still outstanding.
>>
>> Best regards
>>
>> Sara.
>>
>> On 17 Jan 2020, at 15:33, Sara Dickinson <[e-mail]> wrote:
>>
>>
>> On 29 Dec 2019, at 13:50, Mohit Sethi via Datatracker <[e-mail]>
>> wrote:
>>
>> Reviewer: Mohit Sethi
>> Review result: On the Right Track
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-dprive-bcp-op-07
>> Reviewer: Mohit Sethi
>> Review Date: 2019-12-29
>> IETF LC End Date: 2020-01-02
>> IESG Telechat date: Not scheduled for a telechat
>>
>> Summary:
>> This draft discusses privacy challenges for recursive DNS resolvers. It
>> then
>> describes policy and security considerations that DNS service providers
>> can use
>> for enhanced user privacy. The draft is 'On the Right Track' but not yet
>> ready.
>>
>>
>> Many thanks for the detailed review! Ben, Rob I hope theses fixes also
>> address your comments.
>>
>>
>> Major issues:
>>
>> I wonder if section 5.1.2.1/5.1.3.1
>> <https://protect2.fireeye.com/v1/url?k=91d59bed-cd5e90d7-91d5db76-86925ec6fd56-2a24500b228246a8&q=1&e=f2be251d-f590-4578-b7a9-ac8390a7396e&u=http%3A%2F%2F5.1.2.1%2F5.1.3.1>
>> should also talk about recommending OCSP
>> stapling (RFC 6066)? I looked at RFC 8310 and it mentions RFC 7525. Do
>> you want
>> to mention it here in section 5.1.2.1/5.1.3.1
>> <https://protect2.fireeye.com/v1/url?k=5f5ab97a-03d1b240-5f5af9e1-86925ec6fd56-8fb25ccf521d98d2&q=1&e=f2be251d-f590-4578-b7a9-ac8390a7396e&u=http%3A%2F%2F5.1.2.1%2F5.1.3.1>
>> ?
>>
>>
>> What exactly are you thinking of here - something that just says “Server
>> operators should also follow the best practices with regard to OCSP as
>> described in RFC7525”? If something more could you please suggest text?
>>
>> I was hoping that the text would be more precise rather than a cursory
>> reference to another RFC. You could say something along the lines: 'The TLS
>> client and server MUST use Certificate Status Requests [RFC6066] for the
>> server's certificate chain and the client MUST treat a CertificateEntry
>> (except the trust anchor) without a valid CertificateStatus extension as
>> invalid and abort the handshake with an appropriate alert.'. In the same
>> vein, I would expect that you would strongly mandate the use of TLS 1.3
>> with DoH and DNS over TLS?
>>
> Mohit: I actually don't think we should require OCSP at all. For instance,
> most browsers are moving away from it. We should require or at least
> strongly encourage revocation checking.
>
> And what is it being replaced with? i found this blog on OCSP stapling in
> firefox:
> https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/.
> Is there an updated blog post about new techniques for revocation checking?
>

https://blog.mozilla.org/security/2020/01/21/crlite-part-3-speeding-up-secure-browsing/

-Ekr

--Mohit
>
>
> -Ekr
>
>
>
>>
>> In section 5.1.2.1, what is meant by 'authentication domain names'?
>> Later, the
>> text says 'authentication name for the service'. I guess you are implying
>> the
>> authentic domain name of the DNS resolver service that the client software
>> should verify through the common name (CN) in the certificate? Some more
>> explanation here would be beneficial.
>>
>>
>> It is defined in the terminology section of RFC8310:
>>
>> "Authentication domain name: A domain name that can be used to
>> authenticate a privacy-enabling DNS server.  Sources of authentication
>> domain names are discussed in Section 7."
>>
>> I have added a reference for RFC8310 after the first use of
>> ‘authentication domain name’ and made sure every instance of
>> 'authentication name' is updated to 'authentication domain name' for
>> clarity.
>>
>> Personally, I find the phrase 'Authentication domain name' very unclear.
>> From the phrase, it doesn't look like it has anything to do with DNS? On
>> first reading, I interpreted it as the domain name where I should
>> authenticate. Since the IESG let this through for RFC 8310, I guess we will
>> have to live with this (poor) choice.
>>
>>
>>
>> In section 5.1.4, should 'DNS Roadblock avoidance' be 'DNSSEC Roadblock
>> avoidance'? And please add a reference to RFC 8027 here if that is the
>> case.
>>
>>
>> Yes, good catch - will do.
>>
>>
>> Section 5.1.7 says "discussion on the use of Bloom Filters in Appendix
>> A". It
>> is pointing to the wrong appendix.
>>
>>
>> Fixed - thanks.
>>
>> Also, this section talks about implementing
>> traffic monitoring by the DNS service provider. I would argue that in most
>> deployments, the traffic monitoring is required (and implemented) by a
>> different entity. Think of a home network router that has a parental
>> control.
>> Or an enterprise restricting employees from visiting certain sites (to
>> prevent
>> insider attacks)? The impact of encryption is more serious for them and
>> less so
>> for a DNS service provider. What is the BCP advice for them?
>>
>>
>> You are correct that the there are differing concerns but I don’t believe
>> this document should tackle that - the audience of the document is
>> specifically operators of DNS privacy services, typically monitoring to
>> prevent DDoS or similar, not network operators in general (although they
>> may be both in some cases). For the more general case I think the impact is
>> covered in RFC8404 'Effects of Pervasive Encryption on Operators’?
>>
>> I do notice a couple of places where just ‘operators’ is used in the text
>> so could add ‘DNS Privacy Service’ before that to clarify?
>>
>> I leave it to Alissa and IESG to decide what they want here.
>>
>>
>> Also, is it fair
>> to say that this is a best current practice? It feels that we need more
>> experience before we start recommending it as an optimization.
>>
>>
>> Given the specific scope discussed above I think it is fair. The privacy
>> policies of most of the public resolver operators and ISPs that offer
>> encrypted DNS are pretty good today in terms of how they try to minimise
>> the user data retained and I’m sure they all still have monitoring in
>> place…
>>
>> My question was specifically about using Bloom filters? Which DNS
>> operators are currently using it? Do we have sufficient evidence other than
>> the research publication that this is 'Best Current Practice'?
>>
>>
>>
>> This comment applies to all 5.1.1-5.1.8. Each subsection starts rather
>> abruptly
>> by discussing threats. It would be nice if you add a sentence at the
>> beginning
>> of each sub-section telling the reader what are they heading into. This is
>> probably most obvious from section 5.1.8. Without even telling the reader
>> what
>> is a pure TLS proxy, you start listing the DNS privacy threats. Only
>> later on
>> you mention option that operators may implement DNS-over-TLS using a TLS
>> proxy.
>>
>>
>> If we go down this road then I think to be consistent we would need to
>> add text for all 16 sections 5.1.1 to 5.3.3. I could do this but I have a
>> feeling it would be come quite repetitive with respect to the section title
>> text and I think if we could get the titles correct (and possibly add more
>> text to section 5) this might be unnecessary. I suggest:
>>
>> Section 5: Add a first paragraph:
>> “In the following sections we first outline the threats relevant to the
>> specific topic and then discuss the potential actions that can be taken to
>> mitigate them.”thorita
>>
>> And for section 5.1.8 change the title to “Limitations of fronting a DNS
>> Privacy Service with a pure TLS proxy”.
>> Happy to update any other headers you thought too vague.
>>
>> Would that address the issue or do you still think additional text is
>> required?
>>
>>
>> In section 5.3.2 'way and OUGHT obfuscate'. OUGHT is not part of RFC
>> 2119/8174.
>> Why is it capitalized? And, 'ought' ought to be followed by a 'to’.
>>
>>
>> I was confused by this and then realised it is a hangover from a much
>> earlier version of the draft that used EXPECTED/OUGHT/MIGHT keywords
>> defined in the draft to described the various levels of actions…. so as you
>> suggest:
>>
>> OLD: “For example, a resolver with a very small community of users risks
>> exposing data in this way and OUGHT obfuscate this...”
>>
>> NEW: “For example, a resolver with a very small community of users risks
>> exposing data in this way and ought to obfuscate this..."
>>
>>
>> At the beginning of section 5, you describe three classes of actions.
>> However,
>> none of the subsections contain clear "Additional options" that operators
>> need
>> to follow for "maximal compliance”?
>>
>>
>> Sections 5.3.1 and 5.3.2 do have them. In earlier versions several more
>> sections but they have been removed. thorita
>>
>> Okay. Thanks. I hadn't seen this. I have a question related to the
>> following text:
>>
>>    o  Aggressive Use of DNSSEC-Validated Cache [RFC8198 <https://tools.ietf.org/html/rfc8198>] and [RFC8020 <https://tools.ietf.org/html/rfc8020>]
>>       (NXDOMAIN: There Really Is Nothing Underneath) to reduce the
>>       number of queries to authoritative servers to increase privacy.
>>
>> Suppose I own the domain mydomain.com? My application requires clients
>> to lookup for non-existent sub domains. So if a client sends a query to the
>> local resolver for non-existent1.mydomain.com and
>> non-existent2.mydomain.com, will both be sent to the authoritative
>> server for mydomain.com?
>>
>>
>>
>> The document seems focused on TLS 1.2 (and does not talk about TLS 1.3).
>> In
>> fact, RFC 8446 is not even in the list of references even though section
>> 5.1.3.1 mentions it. Similarly, Appendix A.2 mentions TLS session
>> resumption
>> without server-side state. How about servers using TLS 1.3 and PSK
>> resumption?
>> RFC 8446 has text on client tracking in appendix C.4:
>> https://tools.ietf.org/html/rfc8446#appendix-C.4.
>>
>>
>> A slight hangover from the fact the DNS-over-TLS spec was published in
>> 2015 before TLS 1.3 was standardised (so it just says TLS 1.2 or later) and
>> so most of the early DoT services used just TLS 1.2.
>>
>> Section 5.1.3.1 had the text ‘RFC8446’ but it wasn’t actually a reference
>> so I’ve fixed that - thanks.
>>
>> I’ve added a bullet point to Appendix A.2
>> “RFC8446 Appendix C.4 describes Client Tracking Prevention in TLS 1.3"
>>
>>
>> There is something wrong about the last sentence of Appendix A.2 'Note
>> that
>> depending on the specifics of the implementation [RFC8484] may also
>> provide
>> increased tracking'. You already mention RFC 8484 in Appendix A.1 as a
>> means to
>> increase privacy. Perhaps you wanted to cite a different RFC here?
>>
>>
>> The point is that the use of HTTP headers in DoH can add additional
>> privacy concerns over the other DNS transports, but that RFC8484 leaves
>> that as an implementation decision. I suggest replacing the text with
>>
>> “Note that Section 8 of RFC8484 outlines the privacy considerations of
>> DoH. Depending on the specifics of a DoH implementation there may be
>> increased identification and tracking compared to other DNS transports."
>>
>> Think of the reader of this document. Appendix A.1 says that DoH can
>> increase privacy. The Appendix A.2 says that with DoH 'identification and
>> tracking may be increased'  Should I use DoH or not? I recommend to
>> re-phrase the text in A.2 along the lines 'While DoH can increase privacy,
>> section 8 of RFC 8484 outlines potential mechanisms that can nonetheless be
>> used by on-path adversaries for correlation and tracking. As recommended in
>> RFC 8484, DNS resolvers that offer DoH need to consider the benefit and
>> privacy impact of these features, and their deployment context when
>> deciding what features are enabled. Resolver implementations are advised to
>> expose the minimal set of data needed to achieve the desired feature set.'
>>
>>
>>
>> Minor issues:
>>
>> Nits/editorial comments:
>>
>> There is mixed usage of Anonymisation (in Table 1) vs Anonymization. The
>> same
>> with Pseudoanonymisation (in Table 1) vs pseudonymization in text. Please
>> check
>> with the RFC editor on what is expected and use that consistently. Also
>> noticed
>> optimisation.
>>
>>
>> Thanks - have fixed. I have now used the American English forms (z not s)
>> throughout.
>>
>>
>> In Table 1, Crytpographic should be Cryptographic.
>>
>>
>> Ack.
>>
>>
>> Maybe you could use an Oxford comma when using lists of items.
>>
>>
>> Had it some places, but not all - should be fixed now.
>>
>>
>> In section 5.1.2.1, there is stray space character at the end of the
>> bullet on
>> "Follow the guidance in Section 6.5 of [RFC7525] with regards to
>> certificate
>> revocation .”
>>
>>
>> Perhaps expand DNSSEC on first usage: Domain Name System Security
>> Extensions
>> (DNSSEC).
>>
>> In section 5.1.6 'in terms of such options as filtering' should instead
>> be 'in
>> terms of options such as filtering'.
>>
>> In section 5.1.8 'a DNS aware proxy such as [dnsdist] which offer custom
>> (similar to that proposed in'. Consider using 'offers' instead of 'offer'
>> and
>> 'similar to those proposed in' instead of 'similar to that proposed in'.
>>
>> In section 5.2.2 'presents and overview' should be 'presents an overview'.
>> Consider rephrasing 'the better to resist brute force'. Also, in 'agreed
>> solution or any Standards to inform', why is standards capitalized?
>>
>> In section 5.2.4 'queries on multiple TCP session' should be 'queries on
>> multiple TCP sessions'. Please expand CPE on first usage.
>>
>> In section 6.3 'This is by analogy with e.g. several TLS or website' could
>> instead be 'This is analogous to several TLS or website'.
>>
>> In Appendix A.1 'documents apply to recursive to authoritative DNS'
>> shouldn't
>> there be an 'and’?
>>
>>
>> All fixed - thanks.
>>
>>
>> In Appendix C.1, consider changing the format for the sub bullets of
>> '2..  Data
>> collection and sharing.'. Instead of numbering them with 1/2/3, perhaps
>> use
>> a/b/c.
>>
>>
>> I’m currently using markdown which won’t let me do that…. :-( I do think
>> that would be better so I suggest adding a note that this is done at RFC
>> editor time….?
>>
>> Yes, please do. It will help with readability.
>>
>> Thanks for the rest of the changes.
>>
>> --Mohit
>>
>>
>>
>> In Appendix C.1 'of use of system' could be 'of system use'.. Also why is
>> there
>> a line break between 'items that are' and 'included'? There is an
>> extraneous
>> 'the' in 'available with the our threat intelligence'. Consider re-wording
>> parts of paragraph '3. Sharing of data. '. At one place you say 'with our
>> threat intelligence partners' and a few words later you say 'with its
>> threat
>> intelligence partners’.
>>
>>
>> Fixed.
>>
>>
>> In Appendix C.1 'In the event of events or observed behaviors' is a bit
>> hard to
>> parse. Consider rephrasing the 'event of events' part.
>>
>>
>> Replaced events with actions.
>>
>> Best regards
>>
>> Sara.
>>
>>
>>
>>
>> _______________________________________________
>> dns-privacy mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>