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

[nusenu <[e-mail]>]

Martin Thomson:
> 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. 

+1
thanks for writing this down. I agree with your reasoning
regarding the potential external position of the resolver and
the increased attack opportunity/exposure (in contrast
to the mostly local DHCP attack surface).

I'd also like to add that even though most clients probably use DHCP to discover
DNS servers, not all do, and therefore assuming it is fine to use
an unauthenticated mechanism is fine because DHCP is unauthenticated as well,
is somewhat flawed.

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

this makes sense to me.

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

I'm in favor of keeping the DoT step since it provides a path for
deployment even before the new DHCP options are implemented/available.


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

Agreed.




-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu