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

[Neil Cook <[e-mail]>]

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.

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

> The draft contains two proposals that seem to be minimally related.  I would consider splitting them into two drafts.
> 

That is certainly a possibility. Although personally (and this is questioned in the draft itself), I’m not sure that resource-level redirection makes sense given that every unique DNS query could generate a redirect (with caching implications).

> The ".well-known" proposal (Section 6) does what RFC 8484 avoided doing: it proposes an alternative encoding of DNS records in JSON.  As a result, it can only represent a subset of DNS information, with standards work required for each extension.  For example, as currently specified, it cannot represent DNSSEC signatures or the HTTPS RR type.  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 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.

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

> [1] https://tools.ietf.org/html/rfc7231#section-6.4 <https://tools.ietf.org/html/rfc7231#section-6.4>
> [2] https://tools.ietf.org/html/rfc7231#section-6.4.2 <https://tools.ietf.org/html/rfc7231#section-6.4.2>
> On Fri, Aug 28, 2020 at 8:52 AM Brian Haberman <[e-mail] <mailto:[e-mail]>> wrote:
> Hi all,
>      One of the discussion points during IETF 108 revolved around a
> group of DNS-related drafts without a clear place for discussion. The
> DNSOP, ADD, and DPRIVE chairs and ADs convened a few weeks ago to try
> and sort this out. The upshot of that discussion is that
> draft-btw-dprive-rfc8484-clarification should be discussed on the DPRIVE
> mailing list. So, this is a request for WG participants to review the
> draft and provide feedback on the mailing.
> 
> https://datatracker.ietf.org/doc/draft-btw-dprive-rfc8484-clarification/ <https://datatracker.ietf.org/doc/draft-btw-dprive-rfc8484-clarification/>
> 
> Regards,
> Brian
> 
> _______________________________________________
> dns-privacy mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>