[dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-08.txt

[Sara Dickinson <[e-mail]>]

Hi All, 

I think the recent changes have moved this draft in the right direction, but I agree with other reviewers that it could still become more aligned with the other related drafts. So I’ve done quite a detailed review with 2 main goals in mind:

1) Increase consistency between this draft and RFC7858
2) Align it better with the most recent version of the draft-ietf-dprive-dtls-and-tls-profiles draft

My strong preference would be to see these changes made before the document progressed to WGLC, as I think they increase the overall readability. 

With regard to the separate https://tools.ietf.org/html/draft-wing-dprive-profile-and-msg-flows-01 I’ll re-iterate my question from the Yokohama WG: Is there anything DNS specific in the draft? I don’t recall anything particularly DNS specific. I definitely see value in a draft comparing message flows between TLS and DTLS in general, but my feeling is it might be better progressed though another working group with more (D)TLS experts - TLS or UTA?

On the topic of Experimental vs Standards I support the position that implementation work is necessary for this to be considered Standards Track. In particularI think there are 2 areas that need to be directly informed by implementation experience
1) DTLS Session management 
2) Reference implementation of message size calculation and fallback scenarios


Comments on this draft
---------------------------------

Title/Acronym: 

- My suggestion is to change the title to "Specification for DNS over Datagram Transport Layer Security (DTLS)” for consistency with RFC7858, which is called “Specification for DNS over Transport Layer Security (TLS)“ and then also drop the suggested acronym "(DNSoD, pronounced "dee-eon-sod”)”. In draft-ietf-dprive-dtls-and-tls-profiles we use DNS-over-(D)TLS throughout so calling this mechanism simply DNS-over-DTLS feels more consistent.


Abstract: 

- “AS DNS needs to remain fast” - suggest “As latency is critical for DNS” 


1. Introduction:

- Second bullet point, last paragraph: I think it is currently correct that TCP Fast open is not yet ubiquitous but given the recent significant deployment efforts I’m not sure that will remain true for long.  Also, TFO is now available on Windows, Linux, OS X and (server side) FreeBSD.


1.1 Relationship to TCP Queries and to DNSSEC

- s/DNS over TCP could be protected with TLS/DNS over TCP can be protected with TLS/

- I suggest adding an additional paragraph after the first one here with wording similar to that below. I think this is necessary to avoid the kind of confusion that plagued the requirement to implement DNS-over-TCP for many years, or an intermediate state where only partial privacy is available:
“DNS-over-DTLS alone cannot provide privacy for DNS messages in all circumstances, specifically when the DNS-over-DTLS response is larger than the path MTU. In such situations the DNS server will respond with a truncated response (see Section 4). Therefore DNS clients and servers that implement DNS-over-DTLS MUST also implement DNS-over-TLS in order to provide privacy for clients that desire Strict Privacy as described in [draft-ietf-dprive-dtls-and-tls-profiles].”


3.1 Session Initiation

- “DNSoD MUST run over standard UDP port 853 as defined in Section 7.”
—  Interesting. This is a substantially different statement to that made wrt DNS-over-TCP in Section 3.1 of RFC7858, which allows flexibility run over other ports (but not to use port 53). So this seems inconsistent and also more restrictive. It would be nice to have some justification for this if this is the requirement, otherwise this section could use very similar text to that used in RFC7858 here? 
-- I would like to see a statement that clients and servers MUST NOT use port 853 for clear text UDP messages.

- s/The host should determine if the DNS server/The DNS client should determine if the DNS server/

3.2 DTLS Handshake and Authentication

- s/in the event the DNS server upgrades to support DNSoD/to discover if DNS-over-DTLS service becomes available from the DNS server/

- I’d also like to see some statement about how many concurrent DTLS sessions a client should establish to a particular DNS Server (just one?). 

- Second paragraph: It seems the first 3 sentences here are repeating the motivation for authentication already provided in the Introduction. I suggest replacing them with the text “ The client will then authenticate the server, if required. “

3.3 Established Sessions

- Is there anything additional here that can be said about expected session lifetimes or idle timeouts? Is it expected that clients keep session open indefinitely until some sort of error is encountered or can some sort of reasonable idle timeout be suggested? Is there any expectation about whether the client or server typically terminates a session?

- There is a diagram here of a “Message Flow for Full Handshake Issuing New Session Ticket” but is doesn’t appear to be referenced from the text at all - is there a specific reason to include this flow here (I think it is a standard DTLS message flow)? I suggest either to give it some context or remove it.

4. Performance Considerations 

- The first and third paragraphs overlap with the recommendations already made in Section 11 of the draft-ietf-dprive-dtls-and-tls-profiles draft, so perhaps they can be removed or changed to make any DTLS specific points?

- “Since pipelined responses can arrive out of order” - I think the word ‘pipelined’ was accidentally picked up by re-using the text in RFC7858. For DTLS I think it is more correct to just say “Since responses within a DTLS session can arrive out of order “?

- Fourth Paragraph:
— I’m not sure that the discussion of truncated responses is purely a performance issue, I believe is is a protocol issue so would suggest moving this to a section of its own?

-- Question: What does a server do if the client doesn’t send an EDNS0 option? 

-- "The DNS server must ensure that the DNS response size does not exceed the Path MTU”    s/must/MUST?

-- “If the DNS server's response were to exceed that calculated value, the server sends a response...”  Is there a reason this isn't ‘the server MUST send a response”?

-- I do think there is a DTLS Usage Profile specific point to make related to this, which is that if a client gets a truncated answer over DTLS it could choose to fallback to UDP/TCP instead of TLS _if_ it were using an Opportunistic profile which would result in a kind of ‘hybrid’ security.  I don’t really see any advantage in that if TLS is available, but the last sentence is unclear on this possibility, suggesting only TLS can be used - which is correct for Strict Privacy but perhaps not (at least technically) for Opportunistic. This feel worthy of some discussion. 

6. Usage

The draft-ietf-dprive-dtls-and-tls-profiles draft now includes a fairly detailed comparison of Strict and Opportunistic privacy so I wonder if this section can be replaced with a reference to that document, unless there is anything DTLS specific that needs to be said here?

8. Security Considerations

- "The guidance given in [RFC7525] must be followed to avoid attacks on DTLS.”   s/must/MUST or SHOULD?

- “For servers with no connection history…” I think this sentence can also be removed since it is more fully covered in the draft-ietf-dprive-dtls-and-tls-profiles draft.

- “Once a DNSoD client has established
   a security association with a particular DNS server, and outstanding
   normal DNS queries with that server (if any) have been received, the
   DNSoD client MUST ignore any subsequent normal DNS responses from
   that server, as all subsequent responses should be encrypted.”
I think this text is a hangover from the earlier draft when port 53 was used. If clarification is added in section 3.1 then I think clear text and DTLS should only ever happen on separate ports when communicating with a given server?


Minor editorial nits:

- There are several places throughout the document where a space separates a reference from a following punctuation mark (e.g. end of the first and last sentences of the Introduction).
- Abstract: Second paragraph, first sentence:  This sentence starts and ends with very similar phrases which I’m not sure are both needed?
- Introduction: Missing ‘The’ at the start of last sentence of first paragraph?
- Section 3.2: First sentence:  s/with DTLS handshake/with the DTLS handshake/
- Section 3.3: s/When a user of DTLS wishes to send an DNS message, it delivers it to the DTLS implementation/When a user of DTLS wishes to send a DNS message, the data is delivered to the DTLS implementation/
- Sestion 3.4: s/DNSod client and server MUST/DNS-over-DTLS clients and servers MUST/
- Section 3.4: s/DTLS session is terminated/A DTLS session is terminated/
- Section 4:    s/To reduce number of/To reduce the number of/
- Section 4:    s/DNS client and server can use raw public keys [] or/DNS clients and servers can use raw public keys [] and/
- Section 4:    s/Path MTU MUST be greater than equal to/Path MTU MUST be greater than or equal to/
- Section 5:    s/DTLS client receives authenticated/DTLS client receives an authenticated/

Regards

Sara.