Re: [dns-privacy] Mirja Kühlewind's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

Sara Dickinson <sara@sinodun.com> Thu, 05 March 2020 13:17 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C6D3A1471; Thu, 5 Mar 2020 05:17:29 -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 Ag4JGIr84ebf; Thu, 5 Mar 2020 05:17:27 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 6A9A43A146E; Thu, 5 Mar 2020 05:17:27 -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=6NsUItTAyPL+B5q/D2Al+niwh3Gjuvi0Jw/+83PzgYU=; b=b7AI3MYbq3RXuLffc8aWmOsXgZ i86/wmJ6mHBPsZuimI4mGo+YukOdMpGjmblnEDgm9XcL6ia+a+4b9Zftc4AQCWvYJQcNQc7HKyyDm +WuDUMP9Atp9MHvywssGXCnsQXgwIppXv2F5ggItSPI0aSXyMI5Bjf7JB/qLEqTaSKPsqne37dOxG BlfhFo9d14UpNP+XRnpaI7DVP9mZzHbqC1GVjjo6XrZmsJMsYUiGxFl92jVOjw5thTSoMLPFDcALI yZUrFo1lJPxQnoK6Z810Ok3QDrFW56rTIRxvhCsuUa86gDlyxVNAX06fVMbJCc4syvRuUzhs6kPCC SFGOhCVQ==;
Received: from [2001:b98:204:102:fffa::2] (port=53438) 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 1j9qNM-0004Dn-Jp; Thu, 05 Mar 2020 13:17:24 +0000
From: Sara Dickinson <sara@sinodun.com>
Message-Id: <B92CB6BF-047B-40C5-9146-2F63B0EF0966@sinodun.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7E632398-5ACB-4B44-8AA5-33DC794BD233"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 5 Mar 2020 13:17:20 +0000
In-Reply-To: <A9D9E0A9-A178-4BA8-8D18-D7638C9566D4@kuehlewind.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dprive-bcp-op@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dprive-chairs@ietf.org, dns-privacy@ietf.org
To: Mirja Kuehlewind <ietf@kuehlewind.net>
References: <158046754020.21129.5801576555538640582.idtracker@ietfa.amsl.com> <5B5C907C-84E8-43F8-929A-36F5C7C17FC0@sinodun.com> <A9D9E0A9-A178-4BA8-8D18-D7638C9566D4@kuehlewind.net>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/6ybzZkq5JS_6boa0gERHv2RzdgE>
Subject: Re: [dns-privacy] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on?= =?utf-8?q?_draft-ietf-dprive-bcp-op-08=3A_=28with_COMMENT=29?=
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2020 13:17:30 -0000


> On 4 Mar 2020, at 13:37, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
> 
> Hi Sara,
> 
> Thanks for you replies. See below.
> 
> 
>> On 4. Mar 2020, at 14:30, Sara Dickinson <sara@sinodun.com> wrote:
>> 
>> 
>> 
>>> On 31 Jan 2020, at 10:45, Mirja Kühlewind via Datatracker <noreply@ietf.org> wrote:
>>> 
>>> Mirja Kühlewind has entered the following ballot position for
>>> draft-ietf-dprive-bcp-op-08: 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:
>>> ----------------------------------------------------------------------
>>> 
>>> A couple of small comments/questions:
>>> 
>>> 1) RFC2119/RFC8174 disclaimer is present in section 4, however, it does seem to
>>> be the case that normative language is used. I would recommend to actually use
>>> normative language in this doc!
>>> 
>> 
>> There is one key instance of a SHOULD in section 5 which ripples through the entire document because it covers the requirement for the various mitigations. 
>> 
>> “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:"
>> 
>> It is easy to miss though……
> 
> Ah, okay! Actually maybe something that can be stated more explicitly in the intro to make sure people do miss that there are actually normative requirements. (Didn’t re-read the intro, so it might well be that it is clear already and I didn’t get it…)

Given this is the second or third time this has been raised I think that makes sense… How about adding this text immediately after the use of SHOULD in section 5”

“In other words these requirements are specified here as all being normative requirements, and are only classified by different levels of compliance in the rest of the document."

>> 
>>> 
>>> 2) Can you actually provide references for the techniques listed in Table 1?
>> 
>> Do you mean the Categorization/Properties or the actual techniques listed? The latter are described in detail in Appendix B.
> 
> Ah, I didn’t match that on my read. Maybe just add a reference go Appendix B then?

In fact based on other comments the whole table is going to be moved to Appendix B and updated slightly which should make it much clearer I hope!

> 
>> 
>>> 
>>> 3) Sec 5.1.3.1:
>>> “A DNS-over-TLS privacy service on both port 853 and 443.  This
>>>    practice may not be possible if e.g. the operator deploys DoH on
>>>    the same IP address.”
>>> Isn’t 443 basically DoH?
>> 
>> No, this means using the DNS-over-TLS protocol, just on port 443 by prior agreement between client and server (RFC7858 describes this). No HTTPS involved.
> 
> I there is no http, I don’t think this document should recommend use fo 443. See further below. 
>> 
>>> Why would you deploy DoT over 853?
> 
> Sorry I meant 443...
> 
> 
>>> Is that a common practice? Sorry if I miss something…
>> 
>> Port 853 is the IANA assigned port for DoT. Before DoH was a thing, it was suggested that running DoT on 443 would prevent issues where port 853 might be blocked - several early DoT services did this. 
> 
> I was guessing that, but I’m not connivence we should support that in an RFC (given we have DoH on 443 now as well).

There was actually quite some discussion on the DPRIVE list back in December about using port 443 because RFC7858 allowed it and there are use cases for it. The result was registering an ALPN for DoT:
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids <https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids>
A separate IESG comment suggested adding the reference to that registration here which I agree with and that case it seems reasonable to leave this in the document?

Best regards

Sara.