Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-07.txt

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 25 Jul 2016 11:34:23 +0000

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 29 Jul 2016 02:54:05 +0000

> -----Original Message-----
> From: dns-privacy [mailto:[email-masked]] On Behalf Of
> Alexander Mayrhofer
> Sent: Monday, July 25, 2016 5:04 PM
> To: [email-masked]
> 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:
> 
> 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.

> 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-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy