Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers

[Eric Rescorla <[e-mail]>]

On Fri, Jun 26, 2020 at 5:04 PM Paul Vixie <[e-mail]> wrote:

> On Friday, 26 June 2020 22:08:05 UTC Eric Rescorla wrote:
> > ... Other than inelegance, what's problematic about the CNAME approach?
>
> inelegance is permanent, accretive, and earns compound interest. we ought
> not
> dismiss inelegance as the basis for reluctance. inelegance is not
> inevitable
> nor is it automatically acceptable.
>
> > ...
> >
> > The scenario you seem to be interested in is one in which the user joins
> > the network and then learns that the associated Do53 resolver supports
> DoH
> > and then connects to it with whatever coordinates that resolver (or DHCP
> or
> > whatever) provides. That clearly is not useful in the 3552 threat model
> > which assumes that the attacker entirely controls the network because the
> > attacker can just send their own resolver coordinates. That isn't to say
> > that there aren't more limited but still realistic threat models where
> this
> > would be useful, but I think you should start by describing those.
>
> as we describe them, we should also describe their scale, their age, and
> their
> likely lifespan. the 3552 threat model, while it does use the term
> 'pervasive', is nowhere near as common as the SASE (secure access service
> edge) operations model, nor will it ever be. if apps who want to do their
> own
> DNS treat any DoH failure as an attack, and start an arms race of
> spy-vs-spy
> bypass along the lines of Tor, that's going to feel problematic to any of
> us
> whose privately owned securely operated edge networks have a local-only
> DNS
> policy.
>
> RESINFO could probably get better results by using TXT, because of long
> tail
> problems. but ultimately we have to pick a default assumption that we can
> act
> on when secure resolver discovery fails. "OMG it's a 3552 attack" is not
> the
> only interpretation we could think of for this. it's entirely possible
> that
> the most engineering solution to the discovery problem is to fail hard
> when
> the middlebox prevents authenticated policy negotiation, to force
> middlebox
> upgrades. i know that "tough love" is a hard sell, but "assume 3552
> attack" is
> also a form of tough love.
>

Hi Paul,

I think this response perhaps conflates two somewhat different issues,
namely CNAME versus authenticated policy propagation.

Ignoring the question of CNAME for the moment, if a device joins a
network and gets its configuration from that network (e.g., via DHCP),
then it is trusting that network to provide the configuration. So, the
question then becomes what benefit is obtained if that network
supplies a Do[TH] server rather than a Do53 server. In the 3552 model,
we assume the attacker has complete control of the network and can
therefore supply its own server, so it's not clear what the security
benefit is. Conversely, if the network is totally secure and trusted,
then it's *also* not clear what the security benefit is.

So, if we are to have unauthenticated discovery of Do[TH] servers,
then we must have some other threat model. For instance we might
think that the attacker can read all packets but for some reason
can't impersonate the DHCP server. What I'm saying is that we should
start by laying out what that threat model is and then we can define
what, if any, technical measures add security benefit in that threat
model. That would be true even if we knew that there weren't
middleboxes which tampered with new record types.


Two more points, if I may:

1. Where this interfaces with the question of CNAME versus RESINFO
is that RESINFO is much more flexible, but (as above) it's not
clear we can securely make use of this flexibility.

2. It's worth nothing that there are scenarios where the device
can get authenticated network configuration (for instance, if
the device is managed and has had some sort of authentication key
installed). The comments above do not apply to this scenario
but rather to the scenario where you have a naive device joining
a network.

-Ekr