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. _______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
