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

[Sara Dickinson <[e-mail]>]

> On 16 Oct 2019, at 01:59, Patrick McManus <[e-mail]> 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.