Re: [dns-privacy] Review request: draft-btw-dprive-rfc8484-clarification

[Ben Schwartz <[e-mail]>]

On Tue, Sep 8, 2020 at 7:26 AM Neil Cook <[e-mail]> wrote:

> Thanks for reviewing! Some responses inline,
>
> Neil
>
> On 28 Aug 2020, at 15:41, Ben Schwartz <[e-mail]> wrote:
>
> Some commentary on this draft:
>
> Section 3 proposes that there is an apparent inconsistency within RFC 8484
> regarding redirection and URI permissioning.  I disagree: I find the
> meaning of the text in RFC 8484 quite clear and consistent on this point.
> To the extent that some aspects of client and server behavior are not
> specified, this is largely deliberate.  HTTP contains a vast range of
> behaviors that clients and servers might or might not support, including
> following of redirects (which is optional [1]).
>
>
> Well you might find it clear, but before writing the draft the authors
> exchanged emails with the authors of RFC8484 and even they could not
> definitively answer the questions we pose in Section 3.
>

Of course there are many questions that the draft makes no attempt to
answer, including the question of how best to implement redirection.
However, I do not agree that there is an "apparent inconsistency", as the
authors have previously discussed, e.g.
https://mailarchive.ietf.org/arch/msg/doh/cH_kL3tjtOs-y_ZqRe2iQ5_P4TQ/.

>
> On server push, I think this draft contains a misunderstanding.  RFC 8484
> says that clients must not accept and use DNS records that were pushed from
> some arbitrary server that is not the client's configured DoH resolver.
> (That would obviously be unsafe.)  It does not forbid accepting unsolicited
> records that were pushed from the configured DoH server.  (In some
> configurations, unsolicited records of this type would live in a local HTTP
> cache, invisible to the DNS client layer until a matching query is issued.)
>
>
> That might be your understanding. It is not universal, hence the need for
> the clarification.
>

I'm referring to the line "[RFC8484] does not ... clarify that unsolicited
messages from a configured DoH server should be excluded".  This seems
backwards: the requirement does not exist, so there is nothing to clarify.
In fact, such a requirement would be unimplementable in the cache
architecture that RFC 8484 describes.

...

> I would encourage the authors to avoid assumptions about specific RR
> types, and also to explain why CNAME or Alt-Svc is not sufficient for
> server changes.
>
>
> The document goes into detail about why Alt-Svc is not sufficient - the
> first part of Section 5 as well as Appendix A.
>

This explanation only goes one step, by noting that Alt-Svc requires the
destination to be authoritative for the origin.  The question is: why do
you need to redirect the user to a different origin?  There's a hint about
"redirecting the client to a locally administered DoH server", but I wasn't
able to understand the motivation.  What is the system architecture you are
trying to enable, and why?

>
> This proposal seems to assume that there is only one DoH service on the
> domain that is hosting this JSON file.  This is not required by RFC 8484,
> and is already false for some major deployments (e.g. NextDNS).
>
>
> I’m not sure what you mean by this.
>

DoH URIs are full URIs, not merely domain names, so there can be an
unlimited number of DoH servers on a single domain, at different paths,
with different behaviors.  An example of an existing domain with this
behavior is dns.nextdns.io, which has one such DoH path for every user.
The proposed .well-known structure does not appear to support this
configuration: it would collapse all these disparate paths onto a single
destination template.

> The 3XX proposal (Section 7) sends DNS records in the body of a 3XX
> response.  This is interesting but definitely unusual: "The server's
> response payload usually contains a short hypertext note with a hyperlink
> to the new URI(s)." [2].  Also, since following redirects is optional, a
> server using this mechanism would risk losing any non-redirect-following
> clients.  That's acceptable if the query would otherwise have to fail, but
> needs to be mentioned in the draft.
>
>
> Surely any DoH server returning a 3XX would risk losing any
> non-redirect-following clients already, regardless of this draft?
>

Yes, but the draft is encouraging servers to do this, so it needs a warning
label.

On Tue, Sep 8, 2020 at 7:43 AM Neil Cook <neil.cook=
[e-mail]> wrote:

> Do you think that  RFC8484 provides enough information for DNS client and
> servers to implement redirection in an interoperable way?


Yes, insofar as it "might" work, which is all that can be said, since
redirection itself is optional.

Is redirection necessary?


I'm not aware of an important use case for redirection.


> If so do you have any other proposals for how it could be done?
>

Servers can redirect any query except those needed to follow the redirect.

...

> I understand the concern about encoding RRs; the glue records could be
> encoded as per a regular DNS response for example. However given that these
> are glue-style RRs, why would they need to extend beyond A and AAAA? This
> isn’t a general purpose proposal for encoding DNS records in JSON.
>

As I noted, your proposal already breaks client-side DNSSEC validation, and
would prevent use of the new HTTPS RR.  The set of "glue-style" RRs that
might be needed here is evolving, and may continue to evolve.