Hi All, Thanks for doing this work! (draft-ietf-dprive-bcp-op)
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. 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. 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. 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. 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? hth. thanks for the consideration. -Patrick
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
