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

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 Jun 2020 14:27:56 +0000

Apologies for the belated reply.

On May 16, 2020, at 1:09 PM, Ben Schwartz <bemasc=[email-masked]> wrote:

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

Good catch. These sentences were left over from earlier drafts that were about addresses; we'll fix this in the next draft.

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

This is an interesting proposal. We cannot say "MUST" because a resolver cannot empirically know all the domain names that all clients might know it as. However, a resolver that has configuration that says "you are known as $name1 and $name2" could indeed respond to those RESINFO queries on those names, and those responses would be signed if those zones are signed. We'll add this to the next draft.

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

This could be interpreted as a change from being information about this resolver to being information about this or other resolvers, such as "that resolver over there is our preferred DoT resolver". We had that earlier, and it seemed like people didn't like that.

Instead, we could add "dot-hostnames" that would a list of hostnames that this resolver is known by. Would that work for you? If so, that would be good for the draft if the WG adopts it.

> * "The host part of the URI template MUST be an IP address." -> I think this is exactly wrong.  

This seems to spark the most debate.

> IP address certificates provide less security than named certificates, 

It completely depends on the mechanism used by the CA to authenticate domain names; in many cases, IP address certificates have the same assurances as domain certificates.

> and are also dramatically more difficult to acquire.

...currently. This protocol is meant to be used over the long term, not just now.

> I would remove this requirement, and also change the examples to use named URLs.

This, too, is a good discussion if the WG adopts this draft. To be clear: we're not against the use of domain names in the URLs, but we don't want to force them in when they are contentious.

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

If by "we" you mean a specific stub resolver, that is fine: set that variable to "false". There are plenty of use cases where some clients want opportunistic encryption to protect against off-path snooping but cannot authenticate, such as if the client does not have the CA used by the resolver in its trust anchor pile.

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

Excellent points. We'll change this to use the DoH port for HTTP/2, and add something for HTTP/3.

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

Also a good point. We need to do more in the pseudocode to deal with DoH templates that point to resolvers other than the one queried.

> I would replace this entire section with "Do DoH".

That is too simplistic to be useful here.

> * This section is missing "just try TLS on port 853",

Agree. We could add a paragraph that gives that as an example, showing with the inputs for that might be.

> which is the status quo for DoT upgrade.

It is the status quo for one significant implementation, yes. :-)

--Paul Hoffman and Puneet Sood