Hi, i've reviewed the DNSoD document in version -07, and i think that the document is in good shape to proceed to WGLC (I suppose we'd get one or more DISCUSSes from the SEC AD during the IESG review, though ;). I do only have a couple of minor comments:
[Disclaimer: I don't know much about DTLS, admitted] 1) The introduction explicitly lists use cases in which DNSoD provides confidential DNS communication (eg. stub to recursive). What is the reason for "limiting" this to these use cases - and why would DNSoD not provide this property in resolver-authoritative communications? I know the charter does currently not address that side of the DNS, but I don't see any reason why it wouldn't work there. Proposal: change text so that is doesn't seem to exclude the other use cases. 2) I think a sentence that the (wire) format of the DNS messages remains unchanged would be helpful. 3) Editorial: In some cases, adding the document title in front of a reference would improve readability. Eg. "...which can be done with TLS Session Resumption without server state (RFC5077)." Instead of "...which can be done with [RFC5077]." 4) Do I understand correctly that in section 4 we explicitely rule out fragmentation, by limiting response sizes to the Path MTU (rather than the UDP payload size indicated via EDNS0 by the client)? If yes so, why does this only apply to the server? Theoretically, the client could also create a query that exceeds the path MTU... Furthermore, (again, little knowledge of DTLS) is ruling out fragmentation a limitation of using DTLS, or was it a design choice? I think, generally, this section is crucial and should be restructured, eg. splitting off the size calculations from the server requirements. 5) The statement "The largest gain for privacy is to protect the communication between the DNS client (the end user's machine) and its caching resolver." Comes a bit out of the blue - a reference here would be good. Or, alternatively, move this to the introduction or remove it entirely? 6) Section 6: Replace "plain DNS" with "plain text DNS"? Furthermore, change "as modern networks require DNS" to "as modern applications typically require DNS" 7) Some minor restructuring of the Security Considerations section might do good. Eg. splitting the first sentence, like "with a ciphersuite offering confidentiality protection. Guidance given..." would make it clearer. Best, Alex _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
