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

[tirumal reddy <[e-mail]>]

On Sat, 4 Jul 2020 at 06:09, Puneet Sood <puneets=
[e-mail]> wrote:

> On Fri, Jun 26, 2020 at 8:48 PM Eric Rescorla <[e-mail]> wrote:
> >
> >
> >
> > 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.
>
> >From RFC 3552, the threat model for unauthenticated discovery would be
> passive attacks described in section 3.2. There is benefit to
> upgrading from Do53 to Do[TH] even if the network between the client
> and the DHCP server is secure - specifically when the DNS resolver is
> further away on the network. This could be because the network
> operator is running the DNS resolver further away (e.g. DHCP could be
> on the home router for a typical home user) or the DNS resolver
> specified by the ISP is operated by a third-party on a different
> network.
>

Home networks are susceptible to both internal (ARP spoofing/poisoning) and
external attacks (Evil twin, Dragonblood, Krack). Unfortunately
typical home networks use shared WPA-PSK and both WPA2/WPA3 are susceptible
to attacks. The attacker can be active or passive.

-Tiru


>
> -Puneet
>
> >
> >
> > 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
> > --
> > Add mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/add
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>