Hiya, I had an hour so gave this a read. I like the draft but think it's not ready quite yet. Depending on the answer to my question at #1 below, that could all be fixed before or just after the end of the WGLC though but it might take a bit longer as there's more than a teeny bit of work needed I'd say.
Substantive comments and nits below. Cheers, S. #1: I wonder would we be better to wait until some real operators have published DPPPS documents before making this an RFC? I'd expect that there'll be some changes when/if that happens (I'm assuming it's not yet happened but didn't check.) If some such operator has said they'd do that, but want to wait 'till there's an RFC, then that's a good enough reason to go ahead now. If we just don't know, then going ahead and recording this in an RFC is probably ok, but risks this not being followed much or at all. #2: I think a sample DPPPS document should at least exist and be referenced from this or included as an appendix. Is there one somewhere? If not, then I think we really ought fix that before publication. #3: Perhaps we should ask the pearg and httpbis folks if there's any more/better guidance to add to 5.1.3.2? IIRC a pearg presentation at IETF105 seems to have indicated that some h2 session management stuff might also assist with traffic analysis. Checking that out before publication would seem worthwhile in case there's more to usefully say here. #4: 5.1.4: the lowercase "must" for DNSSEC validation is odd. I'd like a "MUST" but perhaps that's not feasible now? #5: given that 1% of zones are signed, and that DNSSEC answers are big, do we think padding is sufficient to prevent an observer from knowing when a qname is in the 1%? If so, great! (But really?;-) If not, is that a problem worth mentioning? And is there anything one could do about it? #6: I don't think mention of "consent" is a good thing to positively recommend operators do as there is (afaik) no good way to really do that. The idea that whatever is behind a DNS stub client can meaningfully "consent" to something is really just broken IMO. (Mentioning that one cannot assume consent is fine, but saying to go get it, when that makes no sense, isn't fine IMO.) Same applies to 6.1.1 item 7. #7: 6.1.1, item 3: "sold or rented" - heh - good luck with that;-) Why not just say doing that's a "MUST NOT"? What operator adhering to this BCP would really be selling or renting the data? I would hope none, and that the BCP calls that out as non-conforming. #8: 6.1.1, item 6: That all looks too heavy to actually be done by any of the bigger folks who use anycast - are we really expecting them to list all the local laws that might apply? What use would that be to someone selecting an operator really? While some information about jurisdictions ought be part of this, I think that needs more thought. nits: - abstract: Is "DNS operators" right? Maybe this is really just "DNS recursive resolver operators" and doesn't include advice for authoritative server operators? Probably better to have the abstract correct. - DPPPS: that's not a great term, hard to say and hard to remember how many P's - I'd suggest a bit of creative bacronyming might be worthwhile - I'll start the bikeshed painting with "DNS Recursive Operator Privacy statement" or "DROP statement":-) - I don't understand the bullet list just before section 5.1, nor the preceding paragraph - what's it trying to say? - 5.1.2: X.509 probably needs a reference to rfc5280, but where do I go to find a definition of an "SPKI pinset"? Later you point to rfc7858 for that but I don't find the term "pinset" used in there - "pin set" (with a space) is used in appendix A there, so maybe that's the reference you want. - 5.1.2: (sadly) maybe it'd be better to remove the mention of the DNSSEC chain extension draft. I suspect it'd just confuse readers of an RFC later. - 5.1.2: Is anyone publishing TLSA for DoT/DoH servers? If so, great! If not, "can also consider" mightn't be worth saying. - 5.1.3.1: the link at [1] seems broken? I didn't check all others, but someone should:-) - 5.1.3.1: Maybe say using RFC8467 or a successor specification? It's pretty early days to be very confident in that RFC. (Much though I like it.) - 5.1.7: Is "Operator" in the section heading here really the operator of the DNS privacy service? Better to be clear about that. People might think you mean n/w operators between the stub and recursive. - 5.2.3: The content of [10] really needs to be in the document body, or else the text above it needs to change. - 5.3.1: The "NOTE" that the authors may add something later needs fixing. - 5.3.2: The "pitfalls" link reference is broken I think. - 6.1.1, item 2: add "and for how long and how those logs are handled" (and maybe more) - this bullet also overlaps with item 3, so maybe it'd be better to re-organise this list a bit? - section 8: A "TODO" there isn't gonna work really:-)
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
