Re: [dns-privacy] wglc feedback draft-ietf-dprive-bcp-op

Sara Dickinson <sara@sinodun.com> Fri, 18 October 2019 12:06 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 E573C120C3C for <dns-privacy@ietfa.amsl.com>; Fri, 18 Oct 2019 05:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 jkRQbw_yB3VO for <dns-privacy@ietfa.amsl.com>; Fri, 18 Oct 2019 05:06:39 -0700 (PDT)
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 47C6A120C3A for <dns-privacy@ietf.org>; Fri, 18 Oct 2019 05:06:39 -0700 (PDT)
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=fIwhwAnZj1vaNqaS9qLWn8GLoaJ7PeNv5sytRDugmaU=; b=gChRMXzps9l//hC7iDwX5Ay5Z7 Myji301PuhsTqEOcqmXG9+rW/+rbwhaebYTYf4JmEfwSjT04dXS+fzdMywNlzkf9tmnmOyvUaM35V 45RNRJIGpsBmxb7oSilOutNKfkgvQfkBGkZaXbq7y6enP/YQvmp4H+Hd3Ra1myrhqwn6uw76UwNA7 rvEnpyv4lEPsB8yM8Xahj672cOseuiB0CUJfgYBoB1pS5WvCwZWOyywvATR3l8Y8krZWq6B0yXCyG L6/uPBp+B6blIi61eHGlJLT71HKPNZlRdBJXKAbnQKv7FVuuNJModg7lcA4K49fnAO/ZHNGosLI2J P5sIsWGw==;
Received: from [2001:b98:204:102:fffa::41e7] (port=57154) 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 1iLR1c-0001c6-Lv; Fri, 18 Oct 2019 13:06:37 +0100
From: Sara Dickinson <sara@sinodun.com>
Message-Id: <D6F4FD45-522C-4480-845B-46A29F09E591@sinodun.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_656E275A-E6F0-4B4C-8388-5C27ADC28B0F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 18 Oct 2019 13:06:30 +0100
In-Reply-To: <CAOdDvNq+d2nT2=ix73-Pq4DDG1gpGS7nPSEGrnORCb8xh1b3bw@mail.gmail.com>
Cc: DNS Privacy Working Group <dns-privacy@ietf.org>
To: Patrick McManus <mcmanus@ducksong.com>
References: <CAOdDvNq+d2nT2=ix73-Pq4DDG1gpGS7nPSEGrnORCb8xh1b3bw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/hXtrviRiUSbLqzhR2eKA3Fp-hLk>
Subject: Re: [dns-privacy] wglc feedback draft-ietf-dprive-bcp-op
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: Fri, 18 Oct 2019 12:06:42 -0000


> On 16 Oct 2019, at 01:59, Patrick McManus <mcmanus@ducksong.com>; wrote:
> 
> Hi All,
> 
> Thanks for doing this work! (draft-ietf-dprive-bcp-op)

Thanks for the review!

> 
> I have a few pretty small comments.
> 
> 1] There is a reference to "run a .onion [RFC7686] service endpoint".
> 
> 1a] The reference to RFC 7686 is not about a service endpoint - it is about the name ..onion and how clients encountering them use them. Its not going to help with what this bcp suggests in terms of a service endpoint.

The best reference I could find for setting up an onion endpoint is https://riseup.net/en/security/network-security/tor/onionservices-best-practices <https://riseup.net/en/security/network-security/tor/onionservices-best-practices>;.  Would this work or do you have another reference to recommend?

> 
> 1b] As this is a BCP, I question whether this is really advice driven by BCP. How often is this done, and when it is done how much traffic is driven through it so that we really understand the implications of it? This feels more like an idea than a BCP backed up by wide experience... and there is reason to think it might fall down at scale if really adopted as a best practice.

I think it is true to say that the majority of the ‘mitigations’ and most of the ‘optimisations' in this document are implemented by one or more of the ‘large’ DoT/DoH providers (https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+privacy+statements <https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+privacy+statements> provides some details.) so it seems reasonable to publish as is. The plan is absolutely to do a -bis in the near future since the deployment is evolving and I hope that as ISPs and Enterprises deploy they will feedback into the -bis.

> 
> 2] "Clients should not be required to use TLS session resumption [RFC5077] with TLS 1.2" can be made a bit better. 
> 2a] how does one require a client to use a resumption method (which is what the text warns about) in any event? Maybe we should say the server should not offer them if it does not want linkability?
> 2b] the explicit reference to session tickets with 1.2 leaves out a bunch of equivalent mechanisms such as ID based resumption and 1.3 based PSKs that create a similar issue. DoH used language like "some form of session resumption mechanism, such as section 2.2 of RFC8446" to try and capture it all. perhaps that's helpful here too.

‘Servers should have no requirement that, to obtain service, clients are required to use any form of session resumption mechanism, such TLS session resumption [RFC5077] with TLS 1.2 or section 2.2 of RFC8446.”?

> 
> 3] "Automate the generation and publication of certificates" could be changed to say "Automate the generation, publication, and renewal of certificates" to explicitly capture the riskiest part. It should also, IMO, include an explicit reference to ACME (as at least an example) as we've got a lot of experience now that ACME is a good way to actively manage certificates through automation.

Good point. How about that bullet point becomes:

* Automate the generation, publication and renewal of certificates. For example, ACME [RFC8555] provides a mechanism to actively manage certificates through automation and has been implemented by a number of certificate authorities.

> 
> 4] I am also concerned that it is unreasonable to suggest TLSA in a BCP document. What are the examples of existing DNS Privacy Services doing so and what are the examples of the matching clients using it? At what scale? Do we have comparable evidence about robust management of that vs the more traditional TLS PKI and ACME and tools built for that? any experience of tlsa with doh at scale before mentioning it as a BCP?

It is currently mentioned as an optimisation - I had thought that after a previous comment on this we had downgraded it to just an ‘additional option’ which I think would be reasonable. There are a DoT few test servers that publish TLSA records: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers <https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers> (I’m not aware of any DoH servers doing this).

Would changing it to an ‘Additional option’ be acceptable or do you feel strongly that it should be removed completely?

Sara.