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

From: Brian Haberman <[email-masked]>
Date: Fri, 28 Aug 2020 08:51:53 -0400

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/

Regards,
Brian

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 28 Aug 2020 10:41:45 -0400

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

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

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

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.

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

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.

[1] 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 <[email-masked]>
wrote:

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 31 Aug 2020 16:50:09 +1000

I agree with Ben on all points (*) and would prefer to see none of the proposed amendments published.

(*) I think that the push qualification is not necessary, but it is not as clearly a misunderstanding as Ben suggests.  It clearly limits this to configured URIs, which seems in line with original intent.  However, it likely denies access to server push in several cases, including after redirects.

On Sat, Aug 29, 2020, at 00:41, Ben Schwartz wrote:
[...]
> The ".well-known" proposal (Section 6) does what RFC 8484 avoided 
> doing: it proposes an alternative encoding of DNS records in JSON.

I would suggest that authors join the "resolver info" beauty contest.  The use of .well-known rather than (for example) a link relation is clearly inferior for the reasons Ben mentions.  But I tend to think that resource records are more appropriate for this particular application, as they work in more cases.

> response.

A client that doesn't follow a redirect isn't much use, so the question for me is whether the client gets the extra info it needs.  It seems to me like clients will follow the redirect and discard any content.  That would lead to the extra stuff being dropped.  I would expect a DoH client to make a separate query if it needed more information to follow the redirect.

A superior design would be to push necessary A/AAAA/CNAME records.  If the client makes a query that ends up at the pushed URI, then this will save time without having to invent novel handling for HTTP messages.