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

Sara Dickinson <sara@sinodun.com> Wed, 04 March 2020 13:33 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8663A0F03; Wed, 4 Mar 2020 05:33:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEgcXFqb6DgQ; Wed, 4 Mar 2020 05:33:12 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6C73A0F14; Wed, 4 Mar 2020 05:33:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=yK1+bmmir3H8MU+SpbfNgeoETx4gE3XiCfmw6YkOpqg=; b=fXxF4RACtu6wCNYqzNstbRghtW uLYG1UZx5s+LreGBNd4q1XfAFIgvAuc1xImxiGyeinqcET0JuHg7jEIHZ/dnhiYAHZAjuP3o/+faK 22zdwvgkgB/eES3L6xM76poK4K1DIji7ZdJSEctHfAM3cwJ/iuXZ4DBlQhylihkn+x/jslZMKE7lp Sftkt65g5LOqJsWfp4ucnIjyy4kXydCEhGFdNbHpzHn+2gObS8cq2G6zHpnv4uTjxyUlBBYhKFtKx Mts8a4xRXPRTu/w1VlwztPeYSDGO5jWaQf4phzaeEf68cbmVGYfzmlmQDssswntBgaLOQ+PGN2h96 BFAKNSCA==;
Received: from [2001:b98:204:102:fffa::2] (port=63226) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <sara@sinodun.com>) id 1j9U93-0001Dt-PS; Wed, 04 Mar 2020 13:33:10 +0000
From: Sara Dickinson <sara@sinodun.com>
Message-Id: <05BC9AFE-D2B6-4A34-B65F-1BFB4540227A@sinodun.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_614F848D-97F4-456D-A752-02496F95D520"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 4 Mar 2020 13:33:02 +0000
In-Reply-To: <825b8c8e-7ee9-9276-d09e-9c006acf3804@ericsson.com>
Cc: General Area Review Team <gen-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, DNS Privacy Working Group <dns-privacy@ietf.org>, "draft-ietf-dprive-bcp-op.all@ietf.org" <draft-ietf-dprive-bcp-op.all@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, Rob Sayre <sayrer@gmail.com>
To: Mohit Sethi M <mohit.m.sethi@ericsson.com>
References: <157762745765.1150.7880025422884493076@ietfa.amsl.com> <2C5DFA70-AD0E-4139-B28E-2D4EDB6E5409@sinodun.com> <46BDE9EB-6306-4194-AFFA-7E9E6604765F@sinodun.com> <825b8c8e-7ee9-9276-d09e-9c006acf3804@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 14
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/bhaPYXw_LLU7lp73NWsWYoedVwA>
Subject: Re: [Gen-art] [dns-privacy] Genart last call review of draft-ietf-dprive-bcp-op-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2020 13:33:17 -0000


> On 10 Feb 2020, at 10:36, Mohit Sethi M <mohit.m.sethi@ericsson.com> 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 <sara@sinodun.com <mailto:sara@sinodun.com>> wrote:
>>> 
>>> 
>>>> On 29 Dec 2019, at 13:50, Mohit Sethi via Datatracker <noreply@ietf.org <mailto:noreply@ietf.org>> 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 <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 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?
>>> 
>>> 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?
> 
Based on the follow up on this topic I will do as Mohit suggests in his email of 11th Feb and do the following:

"For the purpose of this document, I am fine with mandating (or strongly encouraging) revocation checking without mandating OCSP stapling. It is still too early (at least for me) to list CRLite or any variant as a BCP. "




> 
>>> 
>>>> 
>>>> 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. 

Yes - discussed in a separate thread with Alissa

>>> 
>>>> 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’?

I believe that SIDN who did the research are using this in production. The intention here is to list it as one as a number of options for operators to consider since there are many and there are (to my knowledge) no published details on the precise data minimisation techniques used by any of the larger operators so it is hard to recommend a specific technique. 

>>> 
>>>> 
>>>> 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 <http://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 <http://non-existent1.mydomain.com/> and non-existent2.mydomain.com <http://non-existent2.mydomain.com/>, will both be sent to the authoritative server for mydomain.com <http://mydomain.com/>?

Well, it depends… (on whether mydomain.com <http://mydomain.com/> is signed with NSEC/NSEC3 and what other names exist in the zone). I can walk through this offline if you like or have a quick look a sections 3 and 4 of RFC8198 which cover the basics? 

But with regard to the draft did you want to change the text around the existing recommendation?

>>> 
>>>> 
>>>> 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 <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.' 
> 
Alissa suggested turning this into a bullet point that just specifically references section 8 of RFC8484 where the more nuanced discussion takes place. That seems reasonable to me?

> 
>>> 
>>>> 
>>>> 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. 
> 
Ack.

Best regards

Sara. 

> 
> 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.