> On 16 Oct 2019, at 01:59, Patrick McManus <[email protected]> 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.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
