[dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-dtls-and-tls-profiles-09: (with COMMENT)
Adam Roach <adam@nostrum.com> Tue, 09 May 2017 23:28 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: dns-privacy@ietf.org
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7255B124E15; Tue, 9 May 2017 16:28:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dprive-chairs@ietf.org, tjw.ietf@gmail.com, dns-privacy@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149437248346.22508.847522278141179102.idtracker@ietfa.amsl.com>
Date: Tue, 09 May 2017 16:28:03 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ow10K7GeewBQhTrTOsUfVNa19sQ>
Subject: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-dtls-and-tls-profiles-09: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 09 May 2017 23:28:04 -0000
Adam Roach has entered the following ballot position for draft-ietf-dprive-dtls-and-tls-profiles-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The final paragraph of section 6.6 says "The system MUST alert by some means that the DNS is not private during such bootstrap." -- presumably, this means "client" where it says "system" (as opposed to any other part of the infrastructure) -- but I'm having a hard time envisioning how this gets practically implemented, given that the functionality described by this section is going to be implemented in DNS stub resolver libraries, which tend to be pretty far removed from any user interface. Given that this is a MUST-strength requirement, I think it would be very useful to describe what this alerting might look like for (a) interactive applications like a web browser; (b) commandline utilities like curl; and (c) background tasks like software update daemons. This would provide some context for the library implementors to provide the proper hooks to enable this "MUST" to be satisfied. Section 11.1 mentions that it will describe techniques for thwarting DNS traffic analysis, including "monitoring of resolver-to-authoritative traffic". I see that there have been measures added to prevent authoritative servers from determining the identity of the client; but given the phrasing I cite above, I was expecting a description of how to prevent eavesdroppers who can see both incoming and outgoing traffic from the recursive resolver from correlating the encrypted packets I send to that resolver with the plaintext queries it emits for non-cached results. As far as I can tell, there are no described counter-measures against such an attack (aside from hoping that volume of traffic to the resolver is too great to perform such correlation with any real precision), right? If such measures have been defined, I imagine a citation would be warranted. If not, the above phrasing should probably be qualified; e.g., "monitoring of resolver-to-authoritative traffic alone." Nits: draft-ietf-dprive-dnsodtls has been published as RFC 8094 The draft header indicates that this document updates RFC7858, but the abstract doesn't seem to mention this, which it should.
- [dns-privacy] Adam Roach's No Objection on draft-… Adam Roach
- Re: [dns-privacy] Adam Roach's No Objection on dr… Sara Dickinson