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

[Ben Schwartz <[e-mail]>]

On Sat, Mar 30, 2019 at 8:48 AM Martin Thomson <[e-mail]> wrote:

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

What is your view on subsequent unauthenticated connections that _do_
terminate inside the network?  If these are allowed, then we can consider
designs that reduce the need for clients to perform authentication, and
move the point of authentication to a relay or reverse-proxy operated by
the network operator.


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

For clarity, this is the DoT Opportunistic Privacy Profile in RFC 7858
Section 4.1 <https://tools.ietf.org/html/rfc7858#section-4.1>.  It's the
default mode on Android 9 and later.

How would you view an arrangement where the network operator runs a DoT
forwarder at an RFC 1918 address with a self-signed certificate, forwarding
all queries to an external DoT resolver that the forwarder authenticates by
name against a typical root store?

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.
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>