Re: [Doh] Authentication in draft-ietf-doh-resolver-associated-doh-03.txt

["Martin Thomson" <[e-mail]>]

On Mon, Mar 25, 2019, at 12:37, Paul Hoffman wrote:
> The reason I didn't drop down to http: is that doing so evokes the 
> <horror> response, even though you are quite correct that the other two 
> methods given in this document do not offer any authentication. 

There is a different reason that I think is stronger.  We tolerate an exposure on DHCP and other network-layer configuration options (like the v6 RA).  The security implications of those mechanisms are well understood and it is common for networks to deploy systems that limit the opportunity for attacks.  Things like filtering broadcast and RA from end hosts are common.

But the connection to a resolver might be harder to secure in this fashion.  Though it might be possible to narrow the use of unicast port 53 (or 853), such filtering is different.  It is not always the case that the resolver is local in the same way that a DHCP server/relay or gateway is.  For DoH, which might use a service that is completely external to the network, this is more difficult.

Therefore, it is easier to look at this step of the configuration process as being subject to "untrusted" activity and insist on authentication.  It's certainly true that the only basis for authentication is the assertion by the network discovery phase, for which you have no prior expectations.   However, the property we are looking for is that we are talking to the same server that the network intended for us to talk to.  Thus, if the name of the server comes from the same mechanism that gave us an IP address (DHCP), or the system that provides connectivity (RA), then we at least have that much.

If your goal is to talk to the resolver provided by the network, then I believe that to be sufficient.

Hence I would propose a different design for this, bringing DoT into the design.

1. The first step requires no new protocol mechanisms.  To discover DoT, connect to the resolver IP at port 853.  If the server produces a certificate that is valid for the IP address of the resolver, then you are good to proceed.  No new mechanism is required.  (Clients may decide to accept any certificate here if they require opportunistic security, but I would suggest that this is unwise for the aforementioned reasons.  That said, it's better than using Do53, so I'd say it's still worth doing except for the fact that this establishes an expectation on the part of DoT resolvers that having a valid certificate is not required, which is dangerous.)

2. We add a field to DHCP and RA that carries the "DoT resolver".  When this is present, the client resolves this name using the resolver.  This resolution is unsecured.  The client then connects to the resulting IP address and validates the certificate it presents using this name.  This enables easier deployment of DoT because a certificate for a name is easier to get than an IP certificate (it also enables use of 1918 address and the like).

3. We add another field to DHCP and RA that carries the "DoH resolver".  When this is present, the client resolves the associated name using the unsecured resolver.  The client then connects to this endpoint, validates the certificate and proceeds to use DoH.

We could decide not to do the DoT step, but I wanted to include it to illustrate the symmetry of the design.

You will observe that this is significantly simpler than the proposed design.  There are several drawbacks, that I will address:

A. A client in a residential network will not receive this option unless their gateway/relay is configured to relay these values from external network.  The design proposed in the current draft has this property in that the SUDN is forwarded by resolvers that don't understand its purpose.  In this case, endpoints will talk to the DNS proxy in their gateway and not be able to discover a DoH service provided by an ISP.  RFC 5625 points out that it is not generally possible to talk to the external resolver. 

B. This doesn't provide any option for web clients to find the local resolver.  I will separately argue that this is not a valid use case, and moreover that it is one that presents some privacy challenges for clients and networks.  It should not be possible for a web site to be able to use a client's position in the network to access information that it would not otherwise be able to access itself.  Allowing requests to a local resolver might allow access to that sort of information.  Sites are better suited to making requests of configured resolvers.  With DoH, they can make those requests from the client, meaning that the answers will be more suitable for the client's position in the network than their own.  Though this requires that the configured resolver has nodes that are deployed near the client, I believe this to be sufficient.

I think that problem A is pretty significant.  The SUDN option does help there, but it eliminates the weak "authentication" we have.  For anything in this area to work, I think that we would need some other basis for deciding that the DoH server that is identified in this way is OK.  The only idea that I have, which is a poor one, is to configure clients with a list of "trusted" resolvers.  I don't like maintaining these sorts of lists, but it might be the only way to manage it.  No matter what option we choose here, I would prefer that we look at the DHCP/RA steps first.