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

Mirja Kuehlewind <ietf@kuehlewind.net> Wed, 04 March 2020 13:37 UTC

Return-Path: <ietf@kuehlewind.net>
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 EB2373A0EF4; Wed, 4 Mar 2020 05:37:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 tA-cntx-zzhC; Wed, 4 Mar 2020 05:37:52 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3874A3A0EF1; Wed, 4 Mar 2020 05:37:52 -0800 (PST)
Received: from p200300dee7239a0084809b28d0f22131.dip0.t-ipconnect.de ([2003:de:e723:9a00:8480:9b28:d0f2:2131]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j9UDc-00074u-BG; Wed, 04 Mar 2020 14:37:48 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <5B5C907C-84E8-43F8-929A-36F5C7C17FC0@sinodun.com>
Date: Wed, 4 Mar 2020 14:37:47 +0100
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
Content-Transfer-Encoding: quoted-printable
Message-Id: <A9D9E0A9-A178-4BA8-8D18-D7638C9566D4@kuehlewind.net>
References: <158046754020.21129.5801576555538640582.idtracker@ietfa.amsl.com> <5B5C907C-84E8-43F8-929A-36F5C7C17FC0@sinodun.com>
To: Sara Dickinson <sara@sinodun.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1583329072;4def4b58;
X-HE-SMSGID: 1j9UDc-00074u-BG
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/emqGazAhP5mbG1EA7pQ5XPJq34M>
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: Wed, 04 Mar 2020 13:37:54 -0000

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…)
> 
>> 
>> 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?

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

Mirja



> 
> Best regards
> 
> Sara. 
> 
>