Re: [Doh] Subsection Server Push: unclear wording

[Patrick McManus <[e-mail]>]

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

> 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/commi
> t/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.
>
>
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.


> 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.


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
> when contacting a HTTP server that at the same time is configured as a DNS
> API,
> which is exceedingly rare.
>
> I disagree about the rare part.


> Therefore, it would probably be better to specify that only a configured
> DNS API
> server may push DNS responses.
>
> The security requirement falls on the recipient imo.



> 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]
>
>
yep - or decomposition as mentioned above is a possibility.


>
> 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.
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>
>