Re: [Doh] Subsection Server Push: unclear wording

Patrick McManus <pmcmanus@mozilla.com> Fri, 11 May 2018 16:51 UTC

Return-Path: <pmcmanus@mozilla.com>
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 D101D126D05 for <doh@ietfa.amsl.com>; Fri, 11 May 2018 09:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 hH-8OA7TZpvM for <doh@ietfa.amsl.com>; Fri, 11 May 2018 09:51:24 -0700 (PDT)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id C67D01242F7 for <doh@ietf.org>; Fri, 11 May 2018 09:51:23 -0700 (PDT)
Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by linode64.ducksong.com (Postfix) with ESMTPSA id EEA283A04B for <doh@ietf.org>; Fri, 11 May 2018 12:51:19 -0400 (EDT)
Received: by mail-oi0-f41.google.com with SMTP id v2-v6so5278836oif.3 for <doh@ietf.org>; Fri, 11 May 2018 09:51:19 -0700 (PDT)
X-Gm-Message-State: ALKqPwdVWshO/Zj9/mbnbbURgGypVjXj3xcRGUn0hWCgBGDrD87xr1/t n9VXKHJyOWpJAUF+BIpby0e50ZFbxStwb45eLcg=
X-Google-Smtp-Source: AB8JxZripaYPxS2HK5qGEIB3cA0bQxpOqne2Y++Ao7835QkX+UxwFL9zmyX5+9IgbSu1x7aMt4WDrtVFgSjgQ1F7UhU=
X-Received: by 2002:aca:f388:: with SMTP id r130-v6mr3514724oih.17.1526057479654; Fri, 11 May 2018 09:51:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.138.36 with HTTP; Fri, 11 May 2018 09:51:19 -0700 (PDT)
In-Reply-To: <8c412ef6-b92f-2547-d813-643e0e6d83e5@o2.pl>
References: <8c412ef6-b92f-2547-d813-643e0e6d83e5@o2.pl>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Fri, 11 May 2018 18:51:19 +0200
X-Gmail-Original-Message-ID: <CAOdDvNoh5JAp5ruMXXEyMO9a_ZUKU_LUKGwR6zWVRXCBzDweNA@mail.gmail.com>
Message-ID: <CAOdDvNoh5JAp5ruMXXEyMO9a_ZUKU_LUKGwR6zWVRXCBzDweNA@mail.gmail.com>
To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= <mat.jonczyk@o2.pl>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fb59c6056bf0f17b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/iSgPjvRqd-_X6EkBAeY-6ZauMuk>
Subject: Re: [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 16:51:27 -0000

On Fri, May 11, 2018 at 2:17 PM, Mateusz Jończyk <mat.jonczyk@o2.pl> 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
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
>