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

Sara Dickinson <sara@sinodun.com> Mon, 05 October 2015 20:46 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A820A1B4FF1 for <dns-privacy@ietfa.amsl.com>; Mon, 5 Oct 2015 13:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level:
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMUfYwEcRl75 for <dns-privacy@ietfa.amsl.com>; Mon, 5 Oct 2015 13:46:33 -0700 (PDT)
Received: from shcp01.hosting.zen.net.uk (shcp01.hosting.zen.net.uk [88.98.24.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12431B4FE9 for <dns-privacy@ietf.org>; Mon, 5 Oct 2015 13:46:32 -0700 (PDT)
Received: from [216.46.0.94] (port=61731 helo=[172.16.144.2]) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from <sara@sinodun.com>) id 1ZjCeR-0000hV-FX for dns-privacy@ietf.org; Mon, 05 Oct 2015 21:46:30 +0100
From: Sara Dickinson <sara@sinodun.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <879AA0C7-D881-4A57-AF57-AAFA42141660@sinodun.com>
Date: Mon, 05 Oct 2015 16:46:21 -0400
To: dns-privacy@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - sinodun.com
X-Get-Message-Sender-Via: shcp01.hosting.zen.net.uk: authenticated_id: sara+sinodun.com/only user confirmed/virtual account not confirmed
Archived-At: <http://mailarchive.ietf.org/arch/msg/dns-privacy/x8j51BNE1fPRZIzHGYx2VD3kqu0>
Subject: Re: [dns-privacy] review of draft-ietf-dprive-dnsodtls-01
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2015 20:46:35 -0000

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.

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.