[Doh] Alexey Melnikov's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT)
Alexey Melnikov <aamelnikov@fastmail.fm> Thu, 16 August 2018 11:39 UTC
Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: doh@ietf.org
Delivered-To: doh@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B44A12D7F8; Thu, 16 Aug 2018 04:39:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-doh-dns-over-https@ietf.org, Benjamin Schwartz <bemasc@google.com>, doh-chairs@ietf.org, bemasc@google.com, doh@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153441957130.8078.10398621847559233803.idtracker@ietfa.amsl.com>
Date: Thu, 16 Aug 2018 04:39:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/hXhLPKmF6jzCpKTMa4YJJIg6Z1w>
Subject: [Doh] Alexey Melnikov's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.27
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2018 11:39:31 -0000
Alexey Melnikov has entered the following ballot position for draft-ietf-doh-dns-over-https-13: 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-doh-dns-over-https/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is an important piece of work, so thank you for doing this work. The document is well written. I am looking forward to seeing answers to Ben's questions/comments (I agree with them). I also have some comments of my own: 1) I think you should keep Section 3. Maybe make it an Appendix. It would be important to have it if the document gets extended in incompatible ways and some of the requirement/assumptions states in your document are violated. 2) Related to section 3: is there any desire in the WG to work on an extension which would allow for cases when a single request might result in multiple responses? 3) In 3.1: o Supporting other network-specific inferences from plaintext DNS queries Can you please decode this for me, as I don't understand what this is trying to say. Maybe provide an example? 4) In 5.1, next to the last para: In order to maximize cache friendliness, DoH clients using media formats that include DNS ID, such as application/dns-message, SHOULD use a DNS ID of 0 in every DNS request. HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as application/dns-message. The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. Not being that familiar with DNS (and not having read the whole document at this point) I didn't know whether this was talking about some kind of DNS specific thing or whether it was talking about something specific to DoH. At some point I was wondering if DNS ID was supposed to be included in some kind of URL. So maybe you should add a reference where you mention "DNS ID" for the first time. 5) In Section 8.1: Security considerations: The security considerations for carrying this data are the same for carrying DNS without encryption. I think you should do much better then this. This field is supposed to give a quick hint whether there is any active content(*) (e.g. executable code) in the described media type, so that people implementing firewalls and antispam can decide whether anything special needs to be done to process the media type. But what you did is effectively sent me to read all DNS related RFCs on the topic. So please also state whether active content is allowed here. (*) - among other things 6) In Section 11, 3rd para: Some HTTPS client implementations perform real time third-party checks of the revocation status of the certificates being used by TLS. If this check is done as part of the DoH server connection procedure and the check itself requires DNS resolution to connect to the third party a deadlock can occur. The use of OCSP [RFC6960] servers or AIA for CRL fetching ([RFC5280] Section 4.2.2.1) are examples of how this deadlock can happen. To mitigate the possibility of deadlock, DoH servers SHOULD NOT rely on DNS-based I might be confused here, but I thought the most typical is for a DoH *client* to validate DoH *server's* certificate for being revoked. So did you mean "DoH client" instead of "DoH server" above? If not, then I think you lost me and this text needs to be rewritten to be more specific about what the problem is. references to external resources in the TLS handshake. For OCSP, the server can bundle the certificate status as part of the handshake using a mechanism appropriate to the version of TLS, such as using [RFC6066] Section 8 for TLS version 1.2. AIA deadlocks can be avoided by providing intermediate certificates that might otherwise be obtained through additional requests. Note that these deadlocks also need to be considered for server that a DoH server might redirect to.
- [Doh] Alexey Melnikov's No Objection on draft-iet… Alexey Melnikov