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

Mohit Sethi M <> Mon, 10 February 2020 10:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CB67120123; Mon, 10 Feb 2020 02:36:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8HSd0VAb4oIf; Mon, 10 Feb 2020 02:36:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02EA112011E; Mon, 10 Feb 2020 02:36:04 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=GA1bavMH53apFj9xWcvyfk+Vl1zraQj8TnWz05LVcuCeZGGIaMX+yaM6pCZENd+zQd5wOsohNVrUqYQCa+hwNVqGkdBHovsUGgmAPGHS+GU/9sxKvHzFsnhKjMheXIu8y/JSfLoEPqHjwL+uDjEG8OYbkPmsUvZAvpA84g3vzK+qV8lpVYB2gGgCpIHXOTBB9PpYeUrKUksZTXzOEmzue8f0edBJsJ5nSdSVJKN2HKW3By4i7KXs0S3Agk04DI96XhrQ3bKmIszoCFAe8xP+5MOOPDdR5R5/4RssO6HbeUI8nrcfYg/IyaMxJ6ffo6zFLL5pLP7c0mD2Hy23kpbL7w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B7nSyA3/T/GCHMbaC3OnxD2NXDd9thhzX54F3A10dyA=; b=Pv3VePtrBvXmIoOQE18wjYHTSITcMqPilzjxZSYTPEf4+PnVg9yMhaGJWtsvpm/zSS/lYE+epeT5aP+4IZzH7uqlK8a2gpZE2odBQMMxOga+La8+pJLlrmI0kvaVAKaO7FvBI8Zc6npqFSmZntNSCVZmToNfyQ5GJMdfZQXDT3LnB/HiAZIUZFjcUymTuz7cSozrHLrIyDofuQ5AHH6sbJn7dSkxXpmgkRaY9U/3L3df1W7g8WCV5bi4zupn6Os9bbk8TiDNOjspW1W3UAw6Hsoums705qQfYTPGk/ElMpkkhZr9RFudRpTsEEB915JHP5iI6M0fQ1Cxd22Ue4G0cQ==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B7nSyA3/T/GCHMbaC3OnxD2NXDd9thhzX54F3A10dyA=; b=vBbyKXOv8L1n2YNhY+5v60n5A4v0LF60V2s+CjJZ3aIZxzH2Ag/yFwINgJIyYEkkEjSexnbDZ07Vs5bXpk8AGdiCDnvWeFH1nYh+xh/V9hep5Sve28kurEY4WZt3vbj8pzxnqBInKXZymsrZbZ3o0G4uYqpXAjyRi6DK6HAy9oA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.18; Mon, 10 Feb 2020 10:36:02 +0000
Received: from ([fe80::cd13:3dbf:1517:c03c]) by ([fe80::cd13:3dbf:1517:c03c%10]) with mapi id 15.20.2729.018; Mon, 10 Feb 2020 10:36:02 +0000
From: Mohit Sethi M <>
To: Sara Dickinson <>
CC: General Area Review Team <>, "" <>, DNS Privacy Working Group <>, "" <>, Benjamin Kaduk <>, Rob Sayre <>
Thread-Topic: [dns-privacy] Genart last call review of draft-ietf-dprive-bcp-op-07
Thread-Index: AQHVzUt7E/CRnr20M0a60hdoScVmhqf5+6AAgBpljgA=
Date: Mon, 10 Feb 2020 10:36:01 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:14bb:180:16da:ba57:b24a:2214:c893]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bfcc55a9-18c8-478f-e6cc-08d7ae150664
x-ms-traffictypediagnostic: HE1PR0701MB2666:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03094A4065
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(376002)(366004)(346002)(136003)(189003)(199004)(36756003)(66476007)(66946007)(6486002)(76116006)(2616005)(66556008)(5660300002)(64756008)(66446008)(54906003)(30864003)(316002)(4001150100001)(8936002)(71200400001)(86362001)(31686004)(8676002)(31696002)(6916009)(66574012)(81166006)(81156014)(2906002)(6512007)(966005)(478600001)(6506007)(53546011)(186003)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2666;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /3cZzDtlP2/rlDnZfeNXP3LVsXCjcxqnyVNYVnNlc9ASkLwx8b7XrvyUpYEN6vkHQxbfgiAqBj6uoeF+MBtAtJR0bC3UfrMVdZZW9y9V1fAA1vouUMC8C+NaWEqnDnuIRuhNIObm1mSlkJOQ1IGf8mcAZPNBxYMFPRYQPwxSKvAitjsv/6Fyvnd2Yk+ofr7D+0O1v442Teua9gHdKz58xk9zmjkWmxpCwfGrQT9TBfuAGcXwx9pAODsjn979o/MKIQrd7PXGQNHoDR81Sm2oup6iW0Po+swX92K/JJ0ZSaR45c4MAasROseMG+7NBtD6nsAlxl/ZxCWnZ2or0CSWH2OBDbyUvmH/NRIoiVfHDgGGLDSO4OaJ0oIbyvgbgVAlm3Htm6RSzQbEclziAvcPShTx+3FwUch28zCKn0xuNLFbJL9DZRxIptknSp5tcBsNOTLKY21jkIhuAkWbtDS9nq1Iatw1QK7zHIZHqmq7LXU2R25KwU3QgCYJStljK4o19mqh2xjgXBKc/X+pKNbDaA==
x-ms-exchange-antispam-messagedata: KW4I0X8pV9NM9ALDRwz2TbWiizDOxB5dSpgPh9qg1DhnDd3uvC7/X/5X9ioMUDNT/dDdmZlKwjT5JCpsNC9WpNSNqVCL1JjJbavN2nPtJAuKqOOQ3HHAXmizJL4pcqRPBDw833gaWDb7ibOINkS8T9oxcJr+NENxnnGxB1wN63Ii5BDZ2BnAsKTHOMdijdMWxpX09XzOZOrF3oa/W2RYwQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_825b8c8e7ee99276d09e9c006acf3804ericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: bfcc55a9-18c8-478f-e6cc-08d7ae150664
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2020 10:36:01.9817 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: gwNELILLhI9kHX5OQU21NIas25hEk2au7a8h8KLPKcBoPbHzsygjJf/DyzT+914HIfKIVllfB6f+Yw+Bu6WoCxigqDzxwCWGcz/MRhFY4Kw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2666
Archived-At: <>
Subject: Re: [Gen-art] [dns-privacy] Genart last call review of draft-ietf-dprive-bcp-op-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Feb 2020 10:36:10 -0000

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:

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


On 17 Jan 2020, at 15:33, Sara Dickinson <<>> wrote:

On 29 Dec 2019, at 13:50, Mohit Sethi via Datatracker <<>> 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


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

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

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?

In section, 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<>] and [RFC8020<>]
      (NXDOMAIN: There Really Is Nothing Underneath) to reduce the
      number of queries to authoritative servers to increase privacy.

Suppose I own the domain My application requires clients to lookup for non-existent sub domains. So if a client sends a query to the local resolver for and, will both be sent to the authoritative server for

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

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

Thanks - have fixed. I have now used the American English forms (z not s) throughout.

In Table 1, Crytpographic should be Cryptographic.


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

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

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.


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


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