Subject: [Doh] draft-btw-add-rfc8484-clarification (was RE: [Ext] [Technical Errata Reported] RFC8484 (6033))

From: <[email-masked]>
Date: Fri, 10 Apr 2020 08:22:31 +0000

Hi Paul, Barry, all,

(+add wg as I guess the draft should be discussed there)

We prepared a document to clarify the redirection issue: https://datatracker.ietf.org/doc/draft-btw-add-rfc8484-clarification/ 

The document specifies also how redirection can be done in DoH. 

Cheers,
Med

> -----Message d'origine-----
> De : Paul Hoffman [mailto:[email-masked]]
> Envoyé : mardi 31 mars 2020 16:48
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked]; David Lawrence; Ben Schwartz; Patrick McManus;
> Murray S. Kucherawy; Barry Leiba; RFC Editor
> Objet : Re: [Doh] [Ext] [Technical Errata Reported] RFC8484 (6033)
> 
> On Mar 31, 2020, at 2:03 AM, [email-masked] wrote:
> > I'm now more puzzled about the intent of the document with regards
> to redirection:
> 
> That's fine, and you are not alone. But the proper resolution of that
> puzzlement is not an erratum, it is a document update.
> 
> --Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 10 Apr 2020 20:23:09 -0400

On venue: ADD is not chartered for core protocol development work, and DoH
is shutting down, so I think the correct venue is probably DNSOP.  However,
you should also get input from HTTPBIS, where there is expertise on HTTP
semantics.

On the draft:
* The draft introduces new MUST-level requirements, so I don't think it can
reasonably be called a clarification.  Sending DNS records in a 3XX
response body, for example, is a novel construction.

* I would remove the HTTP/2 PUSH version of the proposal, which seems more
complicated without much benefit, and I would make the 3XX response body
optional.  If the response body is absent, clients SHOULD resolve the
target hostname in the same way that they resolved the original DoH server
hostname, or fail if this is not possible.

* I think RFC 8484 is pretty clear on the main point in question: HTTP
redirection applies in the usual way, whatever that might be.  Don't trust
DoH URIs from strangers.

* In practice, redirection may have been given little attention because it
doesn't necessarily give us the behavior we want.  For a GET request (where
DoH encodes the query in the URI), a redirect only applies to that specific
query.  A server that is trying to refer users to a different server would
have to redirect each DoH GET individually -- not a recipe for good
performance.  Permanent redirects for all those queries would also bloat
the client's HTTP cache.  Alt-Svc, in contrast, would allow relocating the
whole origin, which seems closer to the intended behavior.

For POST, all queries share a URI, so permanent redirects might work OK.
However, clients are permitted to convert POST to GET (dropping the body)
when encountering a 302 redirect, so only a 308 will work.  However, as
noted in RFC 7238:
   "initial use of status code 308 will be restricted to cases
   where the server has sufficient confidence in the client's
   understanding the new code"

Perhaps support for 308 is now sufficiently universal that DoH servers can
safely rely on it, but I would recommend checking with HTTPBIS.

* Despite all these concerns, I'm glad to see interest in improving DoH,
and I agree that a way to offer an updated DoH URI template would be nice.
If we can't find an elegant solution using redirects, we can find another
way, e.g. an HTTP response header containing the new template.

On Fri, Apr 10, 2020 at 4:22 AM <[email-masked]> wrote:

> We prepared a document to clarify the redirection issue:
> https://datatracker.ietf.org/doc/draft-btw-add-rfc8484-clarification/
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: <[email-masked]>
Date: Fri, 17 Apr 2020 13:17:50 +0000

Hi Ben,

All good points. Thank you.

We updated the draft to take into account your comments and suggestions:

·         We moved the Server Push proposal to an appendix. We prefer to have there to illustrate how that kind of design is complex. We added some text to explain that.

·         We still maintain “MUST” for returning both A/AAAA in a redirect especially when the DoH service is available in another location. We maintain that language because Do53 may not be possible in some configurations (an example is provide in the draft). We may revisit the language as a function of how we solve the issue we discuss in Section 6.

·         We also updated Section 6 to discuss why Alt-Svc is not an option in some redirect scenarios. We also describe a proposal using GET to hopefully avoid some of the issues you raised.

·         We will send a note to httpbis and dnsop WGs for more feedback, but I do think that some aspects discussed in the draft belong to add as well.

The updated version is available at: https://tools.ietf.org/html/draft-btw-add-rfc8484-clarification-01

Comments and suggestions are more than welcome.

Cheers,
Med

De : Ben Schwartz [mailto:[email-masked]]
Envoyé : samedi 11 avril 2020 02:23
À : BOUCADAIR Mohamed TGI/OLN
Cc : Paul Hoffman; Murray S. Kucherawy; [email-masked]; ADD Mailing list ([email-masked]); Barry Leiba
Objet : Re: [Add] draft-btw-add-rfc8484-clarification (was RE: [Doh] [Ext] [Technical Errata Reported] RFC8484 (6033))

On venue: ADD is not chartered for core protocol development work, and DoH is shutting down, so I think the correct venue is probably DNSOP.  However, you should also get input from HTTPBIS, where there is expertise on HTTP semantics.

On the draft:
* The draft introduces new MUST-level requirements, so I don't think it can reasonably be called a clarification.  Sending DNS records in a 3XX response body, for example, is a novel construction.

* I would remove the HTTP/2 PUSH version of the proposal, which seems more complicated without much benefit, and I would make the 3XX response body optional.  If the response body is absent, clients SHOULD resolve the target hostname in the same way that they resolved the original DoH server hostname, or fail if this is not possible.

* I think RFC 8484 is pretty clear on the main point in question: HTTP redirection applies in the usual way, whatever that might be.  Don't trust DoH URIs from strangers.

* In practice, redirection may have been given little attention because it doesn't necessarily give us the behavior we want.  For a GET request (where DoH encodes the query in the URI), a redirect only applies to that specific query.  A server that is trying to refer users to a different server would have to redirect each DoH GET individually -- not a recipe for good performance.  Permanent redirects for all those queries would also bloat the client's HTTP cache.  Alt-Svc, in contrast, would allow relocating the whole origin, which seems closer to the intended behavior.

For POST, all queries share a URI, so permanent redirects might work OK.  However, clients are permitted to convert POST to GET (dropping the body) when encountering a 302 redirect, so only a 308 will work.  However, as noted in RFC 7238:
   "initial use of status code 308 will be restricted to cases
   where the server has sufficient confidence in the client's
   understanding the new code"

Perhaps support for 308 is now sufficiently universal that DoH servers can safely rely on it, but I would recommend checking with HTTPBIS.

* Despite all these concerns, I'm glad to see interest in improving DoH, and I agree that a way to offer an updated DoH URI template would be nice.  If we can't find an elegant solution using redirects, we can find another way, e.g. an HTTP response header containing the new template.

On Fri, Apr 10, 2020 at 4:22 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Paul, Barry, all,

Cheers,
Med

> De : Paul Hoffman [mailto:[email-masked]<mailto:[email-masked]>]
> Cc : [email-masked]<mailto:[email-masked]>; David Lawrence; Ben Schwartz; Patrick McManus;
> On Mar 31, 2020, at 2:03 AM, [email-masked]<mailto:[email-masked]> wrote:

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add