> -----Original Message----- > From: dns-privacy [mailto:[email protected]] On Behalf Of > Alexander Mayrhofer > Sent: Monday, July 25, 2016 5:04 PM > To: [email protected] > Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-07.txt > > > 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.
Discussion of encrypting DNS messages in other use cases has just started in the WG and requires re-charter. https://tools.ietf.org/html/rfc7858#section-1 in the last paragraph explains that other use cases are out of scope of the doc. > > 2) I think a sentence that the (wire) format of the DNS messages remains > unchanged would be helpful. Added. > > 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]." Fixed. > > 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)? Yes, RFC6347 in section 4.1.1 discusses that each DTLS record MUST fit within a single datagram. > If yes so, why does this > only apply to the server ? Because only the DNS response can be larger than 512 bytes, see RFC6891. > 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? DTLS handles fragmentation and reassembly only for handshake messages. In previous versions of this draft we had added support for fragmentation, but removed it based on discussion in the WG. > 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? Moved the above line to Introduction. > > 6) Section 6: Replace "plain DNS" with "plain text DNS"? Furthermore, change > "as modern networks require DNS" to "as modern applications typically > require DNS" Done. > > 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. Updated. Thanks, -Tiru > > Best, > Alex > > > > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
