Re: [dns-privacy] review of draft-ietf-dprive-dnsodtls-01

[Ted Hardie <[e-mail]>]

On Mon, Oct 5, 2015 at 1:46 PM, Sara Dickinson <[e-mail]> wrote:

> Hi,
>
> After chatting with Warren I’m re-sending a very slightly updated version
> of a review which I sent back in August to the DNSOP list instead of DPRIVE
> (doh!)……
>
> QUESTION: The most recent draft still includes the proposal that DTLS
> could run on port 53. In light of the recent early port allocation request
> that covers both TCP and UDP will future versions of the draft continue to
> include the proposal for running DTLS on port 53?
>
>
> 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.
>
>
​First, I think the chances are pretty good that DNS over TLS or DTLS will
deployed side by existing DNS for at least some time, so I'm not sure that
focusing entirely on avoiding fall back here is ta critical point.

That said, the shim layer proposal seems at first glance to a pretty simple
extension of the multiplexing mechanics already described.  That is, you
have the QueryID to allow you to interleave requests; you use that in
demultiplexing responses.  If you have that and the DNS response in the
first DTLS record referencing a QueryID indicates truncation, you look for
further DTLS records referencing the same QueryID, and re-assemble them
with the first using a sequence number.

Yes, that would require more specification than in the document, but it
seems like a reasonable approach and it avoid re-starting the protocol
machinery (which fallback to TLS would do).

Am I missing a complication here?

regards,

Ted







> 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. Also, the TLS 1.3 spec has a 1 RTT handshake
> and proposes 0 RTT exchange based on a long-term (EC)DH share.
>
>
> 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.
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>