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

From: Paul Vixie <[email-masked]>
Date: Wed, 01 Jul 2020 07:54:26 +0000

On Wednesday, 1 July 2020 05:59:51 UTC Ted Lemon wrote:
> On Jul 1, 2020, at 1:34 AM, Paul Vixie <[email-masked]> wrote:
> > as i wrote, there are other network configuration parameters which are
> > also valuable targets, such as outbound proxy settings.
> 
> Who configures those with DHCP? That would be insane.

my IoT devices hate me, because i won't let them speak directly to their 
motherships, and lacking keyboards or ssh listeners, i have no way to tell 
them what proxy they would have to use to be successful. if you want me to 
agree that IoT is insane, i probably will. but it's our world.

> It sounds like a validating stub resolver will fail to work with your
> product.

well, yes and no. i want certain resolutions to fail. these fail. exactly how 
that failure is obtained matters less to me than the failure itself.

> > i think i should have paid more attention at that time, and i apologize.
> > DHCP was always the wrong thing to build, like BOOTP before it, and IPv6
> > address assignment after it. secure hosting networks have to use /30 and
> > later /31 netmasks (one customer per vlan) in order to trust any of this.
> 
> I don’t know what a “secure hosting network” is. Is that an IETF thing?

definitely not an IETF thing. rather, it's the real world.

-- 
Paul

---

From: tirumal reddy <[email-masked]>
Date: Wed, 1 Jul 2020 16:41:01 +0530

> agree that IoT is insane, i probably will. but it's our world.

Secure bootstrapping methods for IoT devices are discussed both inside
(e.g., BRSKI) and outside of IETF (DPP, OCF, OMA).

> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Jul 2020 10:18:51 -0400

On Jul 1, 2020, at 07:11, tirumal reddy <[email-masked]> wrote:
> Secure bootstrapping methods for IoT devices are discussed both inside (e.g., BRSKI) and outside of IETF (DPP, OCF, OMA).

Indeed, there is a lot of interesting work going on in this space. The idea that devices can’t be trusted is accepted by everybody except the people whose business models rely on snooping, and I expect the state of the art to improve continuously. 

That said, commissioning protocols are ways of making link security (e.g. 802.1x) more usable, and have nothing much to do with DHCP. They are generally one-time unless something goes wrong.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Jul 2020 11:39:05 -0400

> Indeed, there is a lot of interesting work going on in this space. The
    > idea that devices can’t be trusted is accepted by everybody except the
    > people whose business models rely on snooping, and I expect the state
    > of the art to improve continuously.

    > That said, commissioning protocols are ways of making link security
    > (e.g. 802.1x) more usable, and have nothing much to do with DHCP. They
    > are generally one-time unless something goes wrong.

While what you say is true, it misses an important point.
Those mechanisms that result in the device having
  a) an identity
  b) a trust anchor to validate local resources

mean that other management protocols (such as DHCP!) can be done securely.
We never could get DHCP security to work, because device never had identities
we could leverage.

This is far afield from whether a *browser* should use a CNAME rather than a
new RR-type for discovery.  It feels to me DNS is being used as a hammer
because browsers don't have access to DHCP.

The same might not be true for more integrated devices, so it would be nice
to have more network focused solutions, and I think that this WG is going in
the right direction there.    I would prefer that OSes took on that mechanism
too, and revealed those choices more clearly to things like browsers.
(that would make me more tolerant of this pragmatic CNAME hack, if I saw a
way in which it could go away)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Jul 2020 11:45:24 -0400

> We never could get DHCP security to work, because device never had identities

That’s sort of maybe a fair point, but is authenticating DHCP when you’ve already authenticated layer two adding any real value?

> because browsers don't have access to DHCP.

This is _precisely_ the sort of thing that RFC6763 does well.  DHCP isn’t a particularly good way of solving this problem. If you want trustworthy information about network services, why not use a service discovery protocol?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 1 Jul 2020 09:45:40 -0700

On Wed, Jul 1, 2020 at 8:39 AM Michael Richardson <[email-masked]>
wrote:

> because browsers don't have access to DHCP

Hmm... Sort of. CNAME is being used rather than another RRType for
engineering convenience reasons.

It's *also* inconvenient to do DHCP, but the real concern there is whether
the local middleboxes etc. will propagate whatever DHCP information is
needed. Consider the case where we have a DHCP option that says 'here is a
DoH server' and the router provided CPE provides that. But if I have a
third party WiFi router, it consumes that option. Does it then propagate
that to the clients? If not, then the DHCP thing is not going to work super
well.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Jul 2020 12:51:03 -0400

On Jul 1, 2020, at 12:45 PM, Eric Rescorla <[email-masked]> wrote:
> It's *also* inconvenient to do DHCP, but the real concern there is whether the local middleboxes etc. will propagate whatever DHCP information is needed. Consider the case where we have a DHCP option that says 'here is a DoH server' and the router provided CPE provides that. But if I have a third party WiFi router, it consumes that option. Does it then propagate that to the clients? If not, then the DHCP thing is not going to work super well.

Here again DNS Service Discovery would address this problem—the browsing domain discovery process could readily discover a static DNSSD configuration at the ISP.  There are even APIs for this on e.g. Windows, Android, Linux and Mac, so you don’t have to use the limited getaddrinfo API.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 01 Jul 2020 19:26:28 +0000

> (e.g., BRSKI) and outside of IETF (DPP, OCF, OMA).

do you see that problem as specific to IoT, or disjoint from RDNS settings?

(i do not.)

-- 
Paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Jul 2020 17:47:29 -0400

> That’s sort of maybe a fair point, but is authenticating DHCP when
    > you’ve already authenticated layer two adding any real value?

Yes. We had an entire WG, SEND, that also fell on that sword. Identities were
too hard a decade ago.

The difficulty in binding layer-2 addresses and layer-3 addresses has been
both a blessing to IP and a problem.

The presence of that grease has permitted all sorts of stupid L2 solutions to
what were really L3 problems.  This has permitted all sorts of innovation to
solve what are often real local problems, usually in the form of middle boxes.
It's hard to fix many L3 end-to-end because the other peer is not under local
control.  But, L2, by it's nature of being local and under the local admins
control, can be persuaded to do lots of things.

It's a problem of course, because every single wired network permits pretty
much every single node to impersonate any other node at the L3 layer.
Many WiFi systems do not put a strong connection between L3 and L2 address
either. Some do.

Some of the problems that we have from this lack of binding include all of
the defenses we have against rogue DHCP servers, RA-Guard, etc.  All things
we invented because of the inability validate the binding.

    > This is _precisely_ the sort of thing that RFC6763 does well.  DHCP
    > isn’t a particularly good way of solving this problem. If you want
    > trustworthy information about network services, why not use a service
    > discovery protocol?

That's a good point.  And browsers ought to be able to do service discovery.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Jul 2020 18:09:02 -0400

> do you see that problem as specific to IoT, or disjoint from RDNS settings?

In the IoT case, we need a good, autonomic mechanism to deploy network
configuration to devices in ways that they really understand.
(Such as your proxy-HTTP setting, which I entirely approve of).

Getting the wrong RDNS settings on an IoT device means that it probably does
not function well (or maybe at all), and it becomes very difficult to do
RFC8520.  (see my draft-richardson-opsawg-mud-iot-dns-considerations-02 )

Getting the wrong RDNS settings on a *desktop* browser is a qualitatively different
thing in my opinion.  It probably operates, but for some uses/users it may be
a problem, either because of the click-trail it leaves, or because of the
censorship that the user experiences.

I think that this is particularly acute for *desktop* browsers, as they do
not in general have the luxury of just picking a different coffee shop.
The people who use them are generally vulnerable in a variety of different
ways.

It is *important* for the browser to be able to clearly indicate what level
of privacy is being experienced.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 01 Jul 2020 22:29:55 +0000

On Wednesday, 1 July 2020 22:09:02 UTC Michael Richardson wrote:
>     > do you see that problem as specific to IoT, or disjoint from RDNS
>     > settings? (i do not.)
> 

speaking as someone who had to create a local responder for 8.8.8.8 in order 
to get my chromecast to believe it had internet connectivity, i think we 
should consider that in the IoT world, there will never be profit from the 
delivery and sale of these devices, only from the services they can offer, and 
the phone-home telemetry they can monetize. google's chromecast already 
ignores the RDNS settings it gets from my DHCP service. therefore, "wrong" is 
in the eye of the beholder, and the interests of IoT buyers are unaligned with 
the interests of IoT sellers. we should consider this negotiation a "hostile" 
one.

> Getting the wrong RDNS settings on a *desktop* browser is a qualitatively
> different thing in my opinion.  It probably operates, but for some
> uses/users it may be a problem, either because of the click-trail it
> leaves, or because of the censorship that the user experiences.
> 

at the moment, i challenge your specificity here. laptops and smartphones and 
datapads all behave the way you're describing for desktops here.

in the future, i will challenge any specificity on this topic, since all nodes 
whether embedded or operated will have the same capabilities and constraints.

> of privacy is being experienced.

i expect that you can get universal agreement on that point. in any case, +1.

-- 
Paul

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Jul 2020 18:51:03 -0400

On Jul 1, 2020, at 6:29 PM, Paul Vixie <[email-masked]> wrote:
> i think we 
> the phone-home telemetry they can monetize.

I think that point is far from clear. Did the company that sold you your incandescent light bulb need to snoop on your network to make a profit? No. They’re doing the cloud thing because it’s easy. Doing it right is _hard_.  Of course, since they have the cloud setup, then they want your data, because why not, but the main reason to use the cloud is simply that the one thing we know always works on a network is reachability to the cloud.  If we want something better than that, we have to do better. This is of course way off-topic for ADD… :)

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 1 Jul 2020 18:56:22 -0400

Hi Paul,

Any view on a matter raised at the recent IAB session - to what extent 
are the behaviors here anticompetitive?

--amr

---

From: Paul Vixie <[email-masked]>
Date: Wed, 01 Jul 2020 23:03:50 +0000

> are the behaviors here anticompetitive?

i am not a lawyer, but i am a lay expert on antitrust law, from personal 
experience. if you can share the URI of the document or transcript, i'll be 
happy to tell you what i think. (i wasn't present at that session.)

-- 
Paul

---

From: Paul Vixie <[email-masked]>
Date: Wed, 01 Jul 2020 23:02:22 +0000

On Wednesday, 1 July 2020 22:51:03 UTC Ted Lemon wrote:
> ... Did the company that sold you your
> incandescent light bulb need to snoop on your network to make a profit?

yes.

> No.

it's good to know the bailiwick of our disagreement.

> ... This is of course way off-topic for ADD… :)

i won't pursue this point further, then.

-- 
Paul

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Jul 2020 19:29:42 -0400

>> incandescent light bulb need to snoop on your network to make a profit?

I’m confused. Your _incandescent_ light bulb?

> it's good to know the bailiwick of our disagreement.

FWIW, I don’t think we disagree: if you have IoT devices that reach out to the cloud to work, I think blocking their access to the cloud makes perfect sense.  However, if all you block is their DNS, that’s not going to go very far toward restricting their access to the cloud.  It’ll work great for devices made by companies who are reasonably trustworthy, but not for devices that are made by companies that are crooked, nor compromised devices.

---

From: Rob Sayre <[email-masked]>
Date: Thu, 2 Jul 2020 22:22:51 -0700

On Wed, Jul 1, 2020 at 4:04 PM Paul Vixie <[email-masked]> wrote:

> i am not a lawyer, but i am a lay expert on antitrust law...
>

This sounds very interesting. I'd love to hear the followup on this one. :)

cheers,
Rob

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 3 Jul 2020 10:25:46 -0400

Hi Rob et al.,

The concern was raised on open mike at the #107 IETF Plenary. All 
standards bodies have antitrust exposure.  Most recognize that exposure 
and have explicit practices and programs dedicated to reducing it.  
Standards making by definition is an antitrust conspiracy.

The "followup" usually occurs through actions by competition authorities 
and judicial litigation.  The IETF's exposure over the years has been 
significant, but ignored and mollified by insurance coverage and a 
"fuzzied" organization, coupled with circumspect affiliations of actors, 
and non-profit devises.  As the anticompetitive behaviour has increased 
in recent years, and judging by recent actions underway, the IETF 
antitrust "free pass" is probably coming to an end, and the new IETF 
Trust LLC should be demonstrating due diligence.  Organizations, 
companies, and individual are potentially culpable.

Yes, the followup should be interesting indeed.

--tony

On 7/3/2020 1:22 AM, Rob Sayre wrote:
> On Wed, Jul 1, 2020 at 4:04 PM Paul Vixie <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

---

From: Rob Sayre <[email-masked]>
Date: Fri, 3 Jul 2020 16:17:39 -0700

On Fri, Jul 3, 2020 at 7:25 AM Tony Rutkowski <[email-masked]>
wrote:

> The concern was raised on open mike at the #107 IETF Plenary.
>

Hi,

It's unclear what you're referring to. You referenced a "recent IAB
session", in addition to the IETF 107 plenary.

Both of those should have links, so it might clarify your point if you
provided them. Also, I think you mean "open mic".

Without more context, I feel these messages are off-topic for this list.

thanks,
Rob

---

From: Puneet Sood <[email-masked]>
Date: Fri, 3 Jul 2020 20:39:10 -0400

On Fri, Jun 26, 2020 at 8:48 PM Eric Rescorla <[email-masked]> wrote:
>
>
>
> On Fri, Jun 26, 2020 at 5:04 PM Paul Vixie <[email-masked]> 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.

-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
> [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Jul 2020 17:44:13 -0700

> specified by the ISP is operated by a third-party on a different

Puneet,

Thanks for your response.

This certainly seems like a reasonable threat model. However, if this *is*
your threat model,
then it seems like it would be rather easier to just have the gateway
router just proxy
to the actual resolver over a secure channel. This would have several
advantages:

1. It would not require defining any new discovery protocol.
2. It would work with any client, even older, non-upgradeable ones.
3. It would allow the gateway router to inspect the traffic and perhaps do
filtering/monitoring/etc.
(This last one seems like it's arguably not an advantage but given that
that device can insert
itself in the middle anyway....)

-Ekr

---

From: tirumal reddy <[email-masked]>
Date: Mon, 6 Jul 2020 17:48:07 +0530

> specified by the ISP is operated by a third-party on a different

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