Re: [Add] New versions of draft-pp-add-stub-upgrade and draft-pp-add-resinfo

[Ben Schwartz <[e-mail]>]

Thanks; I like this version of RESINFO.  Some comments on Section 2:
* "... it can use that configuration to actually be authoritative for the
addresses on which it responds." -> I don't understand what an "address" is
in this sentence.  Does it refer to a reverse-IP name?  Or to the hostname
of the resolver, in cases where the resolver has a known name (e.g.
DNS-over-TLS)?
* "Any query for the RESINFO RRtype that does not have a QNAME of
resolver-info.arpa/IN is meaningless and MUST result in a NODATA or
NXDOMAIN response." -> I would like this to be relaxed (see proposal below).

I have more problems with the "Upgrade" draft:
Section 2.1:
* "dot-ports" -> I think this should be "dot-addresses" in hostname:port
syntax, to enable authentication.  The "hostname" part can be optional to
indicate "same IP, unauthenticated".
* "The host part of the URI template MUST be an IP address." -> I think
this is exactly wrong.  IP address certificates provide less security than
named certificates, and are also dramatically more difficult to acquire.  I
would remove this requirement, and also change the examples to use named
URLs.

Section 3:
* "upgradeNoAuth" -> I think this should be removed.  If the resolver
claims a name, we should always validate, and fail hard if validation fails.
* "start TLS session on resIP port 443" -> I don't understand the intent of
this algorithm, but it does not support HTTP/3, nor URLs with non-default
ports. It also seems to imply that the DoH server must run on the same IP
address as the Do53 server, which is not true for many major deployments. I
would replace this entire section with "Do DoH".
* This section is missing "just try TLS on port 853", which is the status
quo for DoT upgrade.

Proposal: DNSSEC-authenticated RESINFO for named resolvers
Most resolvers are known to the client by their IP (learned via DHCP,
etc.). However, there are some systems (e.g. Android) that allow the user
to identify a preferred resolver by hostname. I propose that any resolver
that is known to its clients by hostname (currently only DoT resolvers)
MUST additionally publish its RESINFO record on its hostname, and clients
MAY query $hostname/IN/RESINFO instead of resolver-info.arpa/IN/RESINFO.
This would enable authentication of RESINFO for clients who perform DNSSEC
validation and have a resolver identified by hostname.

Possible use cases:
* Authenticated DoH to named resolvers without also having to implement DoT
(and without requiring the user to provide the full DoH URI template).
* Authentication and non-repudiability of (TBD) non-upgrade-related
metadata in RESINFO.

On Thu, May 14, 2020 at 1:15 PM Paul Hoffman <[e-mail]> wrote:

> Greetings again. Puneet and I have made fairly major changes to
> draft-pp-add-stub-upgrade and draft-pp-add-resinfo based on the traffic
> from the WG earlier. The drafts are now focused on the much-more-common use
> case of a stub having an IP address that it got over an unauthenticated
> channel such as DHCP, and we thus removed getting the information over
> HTTPS. The new drafts are at:
>
> https://www.ietf.org/internet-drafts/draft-pp-add-stub-upgrade-01.txt
> https://www.ietf.org/internet-drafts/draft-pp-add-resinfo-01.txt
>
> If folks like the new focus, we can ask the WG chairs to adopt them. We
> know that much of the interest in the WG is on discovery, not this simple
> upgrade process, so we figured we could get these done more quickly while
> the bigger discussions are happening.
>
> --Paul Hoffman--
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>