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

From: Ben Schwartz <[email-masked]>
Date: Mon, 1 Apr 2019 17:23:42 -0400

On Sat, Mar 30, 2019 at 8:48 AM Martin Thomson <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: nusenu <[email-masked]>
Date: Wed, 03 Apr 2019 20:34:00 +0000

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

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

> 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

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 04 Apr 2019 11:15:41 -0400

On Mon, Apr 1, 2019, at 23:23, Ben Schwartz wrote:
> 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.

How do you determine that a connection terminates inside the network?  My assumption here is that discovery (DHCP/RA) is privileged, but nothing else.

As for avoiding authentication, I will suggest that is a non-goal.  We want consistent use of the protocol (be it DoT or DoH).

> default mode on Android 9 and later.

Right.  Forgive my sloppy non-use of the correct terminology.
 
> 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?

All I care about is what the client can verify.  A self-signed certificate wouldn't work.  The forwarder could operate at the TCP layer and this would be fine, but clients can't trust the forwarder to do the right thing and just assert that without proof.  What you describe is a MitM attack.

We could talk about the use of an HTTP forward proxy for this, if the networking layer required that, but that is a lot harder to get right.  Then you could talk DoH or even DoT to the real resolver, but you would still have a TLS connection to a server with a valid name.

---

From: Thomas Peterson <[email-masked]>
Date: Wed, 24 Apr 2019 15:49:05 +0100

I agree with Martin on the points around discovery, and as such have 
started an initial draft[0] describing DoH DHCP and RA extensions. 
Feedback from the list would be appreciated, and should there be further 
consensus for this I will also author an additional draft for DoT and 
begin the necessary requests to IANA for assignments.

Regards

0: 
https://thpts.github.io/draft-peterson-doh-dhcp/draft-peterson-doh-dhcp.html

On 30/03/2019 12:48, Martin Thomson wrote:
> 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.
>