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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Sara,

Thanks for the review. Please see inline

> -----Original Message-----
> From: dns-privacy [mailto:[e-mail]] On Behalf Of Sara
> Dickinson
> Sent: Wednesday, August 3, 2016 8:54 PM
> To: [e-mail]
> Subject: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-08.txt
> 
> 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 ?

I don't think other WG will care enough for this draft, maybe the chairs can request reviewers from the above WG's.

> 
> 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 

Changed.

> 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.

The acronym was added as it sounded easy to pronounce.

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

Updated.

> 
> 
> 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.

Removed the second line in the last paragraph.

> 
> 
> 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/

Fixed.

> 
> - 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].”

Good point, updated.

> 
> 
> 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?

Used text similar to RFC7858.

> -- I would like to see a statement that clients and servers MUST NOT use port
> 853 for clear text UDP messages.

Added.

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

Fixed.

> 
> 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/

Replaced.

> 
> - 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?).

Yes, one DTLS session is sufficient. Its already discussed in Section 3.3
<snip>To reduce client and server workload, clients SHOULD re-use the DTLS session. A single DTLS session can be used to send multiple DNS requests and receive multiple DNS responses.</snip>

> 
> - 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. “

I think those 3 sentences are still required to understand the importance of authenticating the DNS server.

> 
> 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?

Yes, updated draft.
NEW:
In between normal DNS traffic while the communication to the DNS server is quiescent, the DNS client may want to probe the server to ensure it has maintained cryptographic state. Such probes can also keep alive firewall or NAT bindings. This probing reduces the frequency of needing a new handshake when a DNS query needs to be resolved, improving the user experience at the cost of bandwidth and processing time.  If the server has lost state, a DTLS handshake needs to be initiated with the server.

> 
> - 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.

Added supporting text.

> 
> 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 ?

Added reference to Section 11 of profile draft.

> 
> - “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 “?

Updated.

> 
> - 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?

Yes, added new section.

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

The maximum DNS response size of 512 bytes plus DTLS overhead will be well within the Path MTU. 
> 
> -- "The DNS server must ensure that the DNS response size does not exceed
> the Path MTU”    s/must/MUST?

Done.

> 
> -- “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”?

No, updated above line to use "MUST".

> 
> -- 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.  

In Opportunistic profile, if server sends truncated response then 
DNS client should first try TLS and if the TLS handshake fails then fallback to TCP.

> 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.

Added following line:
If DNS-over-TLS connection fails and the client is using Opportunistic Privacy profile then the client can fallback to DNS-over-TCP. DNS client can setup both DNSoD and DNS-over-TLS connections in parallel, to reduce the latency to send DNS queries over DNS-over-TLS if the DNS response is truncated over the DNSoD and the client needs the entire response.

 > 
> 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?

Updated section to point to the profiles draft.

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

Fixed.

> 
> - “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.

I don’t think it's discussed in profile draft, please check.

> 
> - “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. 

No, the above line explains that if the DNS client is using DNSoD it must not accept plain text DNS responses arriving on any port. 
Added more details to clarify.

> 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/

Updated draft to address all above nits.

Best Regards,
-Tiru

> 
> Regards
> 
> Sara.
> 
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy