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 <mohamed.boucadair@orange.com> wrote:

> 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:paul.hoffman@icann.org]
> > Envoyé : mardi 31 mars 2020 16:48
> > À : BOUCADAIR Mohamed TGI/OLN
> > Cc : doh@ietf.org; 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, mohamed.boucadair@orange.com 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
>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>

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

Attachment: smime.p7s