Subject: [Doh] Subsection Server Push: unclear wording

From: Mateusz Jończyk <[email-masked]>
Date: Fri, 11 May 2018 14:17:53 +0200

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.

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 11 May 2018 10:48:58 -0400

> https://github.com/dohwg/draft-ietf-doh-dns-over-https/commit/2a4b0b835358d3c4517ae8a038bc86dcf0df04d2

Perhaps you are interpreting "may be used" to mean "is functional"?  Its
meaning here is "is permitted", i.e. permitted by the client
configuration.  I think that the following sentence makes this clear.

> server may push DNS responses.
I think that is both the intent and the effect of this text.  The final
sentence operationalizes the notion of configuration in a way that reduces
ambiguity.

> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Patrick McManus <[email-masked]>
Date: Fri, 11 May 2018 18:51:19 +0200

On Fri, May 11, 2018 at 2:17 PM, Mateusz Jończyk <[email-masked]> wrote:

>         https://github.com/dohwg/draft-ietf-doh-dns-over-https/commi
> t/2a4b0b835358d3c4517ae8a038bc86dcf0df04d2
>
>
Its not necessarily rare One way is simply a persistent connection to a
recursive resolver has some information it anticipates you would need - and
so pushes it.

Another possibility is that the recursive resolver is decomposing a DNS
answer that contains multiple answers with different TTLS into a multiple
HTTP responses with multiple HTTP freshness lifetimes.

Yet another use case happens because HTTP supports multiple origins on a
single connection. So its likely a CDN or hosting service (like AWS) could
host your configured DOH server and also many other origins you are
accessing. A pushed DOH entry under those circumstances meet the stated
criteria. There are other scenarios as well.

There is interest, of course, in updating this with looser criteria. But
that's a future effort.

> as the chosen DNS API server.

close. A pushed DOH exchange contains an HTTP Response (obviously), a DNS
Response in the body of the HTTP Response (obviously), and an HTTP Request
(less obvious to people new to HTTP push). There are a bunch of reasons for
this, but mostly its because HTTP only operates on exchanges (i.e. a
request response pair) so parts of the specification fall apart if you
don't have a request (e.g. the definition of the Vary response header). So
the server makes up a request (known as a PUSH_PROMISE) and a response and
pushes them both.

The HTTP Request URI mentioned in the text refers to the URI in the pushed
request (i.e. the PUSH_PROMISE).

So in your example you need to inspect the pushed request URI and if that a
DNS API server you would normally use and this is a valid push then you can
you use the resolution of foo.com. (valid push is an important part of that
- but that's just part of the 7540 machinery.. the tls certificates of the
connection you are on dictate whether or not that origin can be pushed on
that connection - the origin of the pushed request URI doesn't have to be
the same as the SNI, but it does have to be covered by the cert..
SECONDARY_CERTIFICATES/tls-exported-authenticators are a works in progress
that might be able to dynamically expand the scope of a connection by
adding new certificates to it)

> So, a pushed DNS resolution could only be used
> I disagree about the rare part.

> The security requirement falls on the recipient imo.

> www.deviantart.com, the DNS API server may push a DNS resolution for
yep - or decomposition as mentioned above is a possibility.