Subject: [DNSOP] Review of draft-wing-dprive-dnsodtls-01

From: Sara Dickinson <[email-masked]>
Date: Wed, 5 Aug 2015 17:39:10 +0100

Hi, 

Here are some comments on the draft-wing-dprive-dnsodtls-01 draft (some of which echo comments at the mic from the recent working group meeting).

General comments:
---------------------------

1) My major comment is that I don’t think the current draft tackles the problem of truncation of answers in enough depth. DNS-over-DTLS, like UDP, will have to truncate answers if they exceed the pMTU. And since the packet includes the DTLS header the likelihood of truncation is increased for DNS-over-DTLS compared to UDP.  In the case of truncation one of two things must happen:
  i) Fallback to e.g. TLS (if available) which compromises performance compared to using a single protocol for privacy.
  ii) Fallback to unencrypted communication, which compromises privacy.

There is a brief discussion of a proposed shim layer to avoid this, but without a solution to this issue that eliminates the need for fallback I don’t believe the protocol can be deployed as a standalone solution for DNS privacy (it would have to deployed alongside e.g. TLS). Because of this limitation I think much more weight should be given to this issue and the feasibility of potential solutions.

2) I also think a fuller discussion of the difference between the initial TLS and DTLS handshake should be included since in the DTLS case an extra RTT is needed for the Hello Verification, without which the session resumption cannot occur in 1 round trip. Since DNS is a latency sensitive protocol this should be spelled out in order to ensure implementors fully understand this difference. 

3) Whilst I do not support using port 53 for DTLS as proposed in this document, I do think it may make sense to pursue DTLS on a different port should a new port be assigned as a result of the early port assignment request generated by draft-ietf-dprive-start-tls-for-dns-01 (as discussed in the WG meeting). 

Specific comments:
---------------------------

Terminology

- I wonder if a terminology section would be of use? For example, I see both the terms ‘DTLS session’ and  ‘DTLS security association’ used in the document and it would be helpful to clarify them (or just define one and use it consistently). 

Section 3.3: Downgrade attacks

- I think this section may benefit from adopting the language used in RFC7525 e.g discussing strict vs opportunistic encryption. 

- I think it would help if the second sentence of the first paragraph could be re-written to either make clear that the behaviour is an implementation choice (e.g. use ‘might choose’ instead of ‘will’) or clarify is it part of the specification (e.g. use SHOULD/MAY instead of ‘will')?

Section 7: Performance Considerations

- (nit) Second paragraph s/QueryID/Query ID/ 

- From an implementation point of view I think DTLS probably has more characteristics in common with TCP/TLS than UDP, so detailing behaviours like connection re-use, query pipelining, idle-time, out-of-order responses (or their DTLS equivalents) will be of value.  For example:

-  I’d like to suggest the second paragraph includes some text similar to that in draft-ietf-dnsop-5966bis-02 which addresses message ID collisions:
“ When sending multiple queries over a DTLS security association clients MUST take care to avoid Message ID collisions. In other words, they MUST not
   re-use the DNS Message ID of an in-flight query.”
- Similarly, I also think some text clarifying that clients should sent multiple queries on a given security association without waiting for responses wouldn’t go a miss. 
- Third paragraph. Did you consider adding a statement to the effect “Clients SHOULD re-use security associations.” Is there any reason not to add this?
- I think it would be helpful to add some discussion of the expected lifetime of the UDP security associations. Also, it is unclear to me what happens in a ‘normal’ tear down of the security association.

- Fourth paragraph 
   — I think it would be helpful to clarify for implementors that the DNS server implementation must be capable of determining the encoded size of the message (not the clear text size) before it is sent in order to evaluate if the TC=1 bit must be set. 
    — I think your argument about the use of pMTU to reduce the need to switch to TCP is that a client can use the pMTU in a server selection algorithm? 

- You make the recommendation that root servers should not implement this due to additional load. I disagree with the NOT RECOMMENDED here as I think it is too prescriptive. I agree with dkg’s earlier comments that the authoritative server resource discussion would be improved by being more general. 

Section 8: Established session

- I’d like to suggest moving this entire section earlier to improve the readability of the document, perhaps after section 4?

- Again, I think a stronger/clearer recommendation (SHOULD?) about re-using DTLS sessions would be helpful here too

Section 9:

- Perhaps this section is better replaced with a reference to RFC7525?

Section 12:

- Could the following sentence be reworded as I find it unclear. What is ’a normal DNS query” here - I think it should be 'unencrypted DNS query'? And would  “all subsequent responses should be encrypted using DNSoD” read better? 
   ”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
   inside DNSoD.”

- I think this section might benefit from a discussion of DoS mitigation techniques? E.g. should a server limit the number of DNSoD security associations accepted from a single client? 

Regards

Sara.