[Doh] Subsection Server Push: unclear wording

Mateusz Jończyk <mat.jonczyk@o2.pl> Fri, 11 May 2018 12:18 UTC

Return-Path: <mat.jonczyk@o2.pl>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AFE12702E for <doh@ietfa.amsl.com>; Fri, 11 May 2018 05:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 wYPrv7BWahK0 for <doh@ietfa.amsl.com>; Fri, 11 May 2018 05:18:12 -0700 (PDT)
Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D25120227 for <doh@ietf.org>; Fri, 11 May 2018 05:18:11 -0700 (PDT)
Received: (wp-smtpd smtp.tlen.pl 27609 invoked from network); 11 May 2018 14:18:08 +0200
Received: from agtn205.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.117.205]) (envelope-sender <mat.jonczyk@o2.pl>) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for <doh@ietf.org>; 11 May 2018 14:18:08 +0200
To: DoH WG <doh@ietf.org>
From: Mateusz Jończyk <mat.jonczyk@o2.pl>
Openpgp: preference=signencrypt
Message-ID: <8c412ef6-b92f-2547-d813-643e0e6d83e5@o2.pl>
Date: Fri, 11 May 2018 14:17:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="FRC6xaA6BG7cz9RNU7yNxGLAFe9pbJ5t3"
X-WP-MailID: ac13c42fb2766d5689848c8d55b52b83
X-WP-AV: skaner antywirusowy Poczty o2
X-WP-SPAM: NO 000000A [ccME]
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/VBuRxhaM46YLFs5o498-p3or7WI>
Subject: [Doh] Subsection Server Push: unclear wording
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Fri, 11 May 2018 12:18:13 -0000

Hello,
The Server Push subsection now reads so:

	Before using DOH response data for DNS resolution, the client MUST
	establish that the HTTP request URI may be used for the DOH query. For
	HTTP requests initiated by the DNS API client this is implicit in the
	selection of URI. For HTTP server push ({{RFC7540}} Section 8.2) extra
	care must be taken to ensure that the pushed URI is one that the client
	would have directed the same query to if the client had initiated the
	request.

The first sentence is very misleading. The intention here was supposedly that
the HTTP request URI is trusted by the client, not that it is working. This is
clear by reading the commit that introduced the sentence:
	https://github.com/dohwg/draft-ietf-doh-dns-over-https/commit/2a4b0b835358d3c4517ae8a038bc86dcf0df04d2


Additionally, I do not understand it fully, but to me it seems that the
situation described as "the pushed URI is one that the client would have
directed the same query to if the client had initiated the request." would be
very rare.

Suppose that the client connects to example.com, and example.com tries to push a
DNS resolution for foo.com. It seems (as I get it) that the client could only
use the DNS resolution of foo.com when example.com is configured by the client
as the chosen DNS API server. So, a pushed DNS resolution could only be used
when contacting a HTTP server that at the same time is configured as a DNS API,
which is exceedingly rare.

Therefore, it would probably be better to specify that only a configured DNS API
server may push DNS responses.



On the other hand, it may happen that the DNS API server pushes additional
responses to a DNS query. For example, when the DNS client requests an AAAA
record for milk-and-pie.deviantart.com and it happens to be an alias for
www.deviantart.com, the DNS API server may push a DNS resolution for
www.deviantart.com. [1]


Am I reading the text correctly here?

Greetings,
Mateusz Jończyk

[1] I have to admit I do not know DNS well enough to know whether such server
push could be beneficial and when.