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

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

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

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

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

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

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.