Subject: [Add] EER bootstrapping draft scopes

From: Tommy Jensen <[email-masked]>
Date: Mon, 16 Nov 2020 09:48:03 +0000

(Martin, I see you just touched on the 15% comment on another thread; I figure this deserves a separate thread)

One of the DEER feedback points that came up during the Monday session was that it addresses a minority of cases (someone threw out 15%). I'm surprised to hear folks consider that a blocker to adoption considering the advice from the chairs following the interim to try and clearly define solution scopes. My takeaway from that was it would make sense to have multiple, cleanly-scoped solutions as opposed to a monolithic solution for every scenario.

We feel breaking up the different scenarios makes sense given the wide variety of different requirements each solution has. DEER is presented as a way to verify bootstrapping from a public IP address, with an opportunistic (not verifiable) method for same IP address. Another major scenario is for an RFC1918 forwarder to refer to an upstream resolver given the CPE cannot be updated with a same-IP EER. Does it not make sense to let a single draft focus on that scenario that isn't required to also authenticate public server bootstrapping?

If the two scenarios end up with different security guarantees (which seems probable), I think it makes sense to have different mechanisms so adopters can choose to do one or the other or both depending on their needs.

Thanks,
Tommy

---

From: Jim Reid <[email-masked]>
Date: Mon, 16 Nov 2020 10:02:48 +0000

> On 16 Nov 2020, at 09:48, Tommy Jensen <Jensen.Thomas=[email-masked]> wrote:
> 
> My takeaway from that was it would make sense to have multiple, cleanly-scoped solutions as opposed to a monolithic solution for every scenario.

Me too!

If the WG tries to find a single over-arching monolithic solution for every scenario, we might as well boil the ocean. That would be much quicker and use less energy.

---

From: Eric Orth <[email-masked]>
Date: Mon, 16 Nov 2020 05:03:56 -0500

My take: The best bang-for-buck case we could figure out a solution for is
dealing with upgrading users currently configured to use a legacy home
router that cannot do encryption or advertise a different IP.  I think it's
the biggest problem that many clients don't have any story to do.  But that
doesn't mean DEER's more limited case is not also a worthy problem to
solve, and it seems to fit well into the spirit of simpler drafts scoped to
individual cases.

And since I'm the source of the 15% stat, I should clarify: Only
approximately 15% of Chrome users have a non-private IP configured as the
DNS server.  I don't have any data on what portion of that remaining 85%
can or cannot run encrypted DNS on that same private IP, or what portion
could potentially have an ISP or similar reconfigure to point DHCP at a
non-private IP, so DEER could potentially still be applicable for much more
than just that 15%.

On Mon, Nov 16, 2020 at 4:48 AM Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> One of the DEER feedback points that came up during the Monday session was
> that it addresses a minority of cases (someone threw out 15%). I'm
> surprised to hear folks consider that a blocker to adoption considering the
> advice from the chairs following the interim to try and clearly define
> solution scopes. My takeaway from that was it would make sense to have
> multiple, cleanly-scoped solutions as opposed to a monolithic solution for
> every scenario.
>
> We feel breaking up the different scenarios makes sense given the wide
> variety of different requirements each solution has. DEER is presented as a
> way to verify bootstrapping from a public IP address, with an opportunistic
> (not verifiable) method for same IP address. Another major scenario is for
> an RFC1918 forwarder to refer to an upstream resolver given the CPE cannot
> be updated with a same-IP EER. Does it not make sense to let a single
> draft focus on that scenario that isn't required to also authenticate
> public server bootstrapping?
>
> If the two scenarios end up with different security guarantees (which
> seems probable), I think it makes sense to have different mechanisms so
> adopters can choose to do one or the other or both depending on their
> needs.
>
> Thanks,
> Tommy
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 16 Nov 2020 21:09:25 +1100

On Mon, Nov 16, 2020, at 20:48, Tommy Jensen wrote:
> One of the DEER feedback points that came up during the Monday session 
> was that it addresses a minority of cases (someone threw out 15%). I'm 
> surprised to hear folks consider that a blocker to adoption considering 
> the advice from the chairs following the interim to try and clearly 
> define solution scopes.

I don't.  I even think that DEER *might* help for more than the 15%, as I pointed out during the meeting.

It all depends on your posture.  If you start off with the assumption that you will take whatever you will get, then you might be able to use DEER for the other 85% as well.

Of course, that doesn't make DKG or Ekr happy about the security properties of the situation.  You don't get to learn what your resolver is doing with queries.  For that you need a reference identity.  But then I'm not sure that DHCP/RA are up to providing anything worth relying on their either.  For that we all seem to be relying on lists right now.  Mostly.  DEER does seem to offer some hope if you have some reliable way of getting that reference identity.

---

From: tirumal reddy <[email-masked]>
Date: Mon, 16 Nov 2020 17:12:03 +0700

I consider DEER to complement encrypted resolvers that cannot be discovered
via DHCP/RA (see https://tools.ietf.org/html/draft-btw-add-home-10).
Upgradable CPE can host a DoH/DoT forwarder and DHCP/RA can be used to
discover the network-provided encrypted resolver. IP address matching is
not required to prove equivalence for network-identified encrypted
resolvers.

In case of Legacy CPE, DEER can be used to discover the encrypted
DNS server hosted by the ISP.

-Tiru

---

From: Ray Bellis <[email-masked]>
Date: Mon, 16 Nov 2020 10:55:32 +0000

On 16/11/2020 10:03, Eric Orth wrote:

> approximately 15% of Chrome users have a non-private IP configured as
> the DNS server.  I don't have any data on what portion of that remaining
> 85% can or cannot run encrypted DNS on that same private IP, or what
> portion could potentially have an ISP or similar reconfigure to point
> DHCP at a non-private IP, so DEER could potentially still be applicable
> for much more than just that 15%.

Pretty much every last-mile access technology will deliver a set of DNS
servers to the CPE, whether by DHCP or PPPoE parameters.

Many CPE will not pass those addresses on to the client devices, they
issue the routers own internal address (typically RFC 1918) in the CPE's
own DHCP leases.

One reason for this is because it avoids the chicken and egg scenario of
what DNS servers to put in the client lease if the CPE is not online and
had not yet acquired its own upstream lease.  This is particularly
common on xDSL technologies where the time to "sync" the WAN port on
power-up is quite long.

Ray

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 16 Nov 2020 12:20:37 -0800

> On Nov 16, 2020, at 2:09 AM, Martin Thomson <[email-masked]> wrote:
> 

Agreed. The mechanism in DEER can be used with looser restrictions (creating a variation of the Opportunistic mode where you’re allowed to use a different IP address as long as some conditions are met). We can restrict it to only private addresses; and clients could choose to limit the resolver identities they will trust through this mechanism.

> Of course, that doesn't make DKG or Ekr happy about the security properties of the situation.  You don't get to learn what your resolver is doing with queries.  For that you need a reference identi…

Right—if you want to have something that you can prove matches your reference identity, I think there may not be any way to get those guarantees on a network with a forwarder running on a private IP address that can’t ever update DHCP and can’t add its own encrypted DNS support. Arguably, for those cases, you are technically using a resolver (which does little more than forwarding and filtering) that simply has no equivalent encrypted resolver and will never have one. You may be trying to figure out the equivalent encrypted resolver for whatever the forwarder is talking to, but unless you have a trusted way to find out what that entity is, you don’t have many options.

Let’s find a way to make a solution like DEER work “well enough” for that case, with many caveats about how you can’t really trust it, and put limits on when and how this mode is used. But it’s important to also define the stronger mode of validation, so we can at least have a model that networks going forward can adopt and we can point to. There will always be some old router deployments, so let’s work with those, but let’s not stop ourselves from designing a system that can provide better assurances for other deployments (which will hopefully become increasingly common).

Tommy

---

From: Andrew Campling <[email-masked]>
Date: Mon, 16 Nov 2020 21:56:01 +0000

On the 85% figure, when we did the operator observations draft to document the DNS forwarder / RFC 1918 usage for IETF 108 (see https://datatracker.ietf.org/doc/draft-campling-operator-observations/?include_text=1), the stats from the larger ISPs suggested around 90% of their consumer base used their DNS resolvers, however there are of course some ISPs that outsource DNS to cloud providers so 85% seems to be in the right ballpark overall.  We didn’t look at the % of the CPE base that could be upgraded but noted that some units were up to ten years old, with 60-80% of the base typically ISP-provided and managed (there was some variability here).

Andrew

From: Eric Orth <[email-masked]>
Sent: 16 November 2020 10:04
To: Tommy Jensen <Jensen.Thomas=[email-masked]>
Cc: [email-masked]
Subject: Re: [Add] EER bootstrapping draft scopes

My take: The best bang-for-buck case we could figure out a solution for is dealing with upgrading users currently configured to use a legacy home router that cannot do encryption or advertise a different IP.  I think it's the biggest problem that many clients don't have any story to do.  But that doesn't mean DEER's more limited case is not also a worthy problem to solve, and it seems to fit well into the spirit of simpler drafts scoped to individual cases.

And since I'm the source of the 15% stat, I should clarify: Only approximately 15% of Chrome users have a non-private IP configured as the DNS server.  I don't have any data on what portion of that remaining 85% can or cannot run encrypted DNS on that same private IP, or what portion could potentially have an ISP or similar reconfigure to point DHCP at a non-private IP, so DEER could potentially still be applicable for much more than just that 15%.

On Mon, Nov 16, 2020 at 4:48 AM Tommy Jensen <Jensen.Thomas=[email-masked]<mailto:[email-masked]>> wrote:
(Martin, I see you just touched on the 15% comment on another thread; I figure this deserves a separate thread)

Thanks,
Tommy
--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2020 14:21:40 -0800

On Mon, Nov 16, 2020 at 1:56 PM Andrew Campling
<[email-masked]> wrote:

> On the 85% figure, when we did the operator observations draft to document
> the DNS forwarder / RFC 1918 usage for IETF 108 (see
> https://datatracker.ietf.org/doc/draft-campling-operator-observations/?include_text=1),
> the stats from the larger ISPs suggested around 90% of their consumer base
> used their DNS resolvers
>

Does this distinguish between directly and indirectly. For instance,
devices on my network (other than Fx, obviously) use the ISP-provided
resolver but my AP DHCP vends a 1918 address and presumably proxies that in
some way.

-Ekr

, however there are of course some ISPs that outsource DNS to cloud
> providers so 85% seems to be in the right ballpark overall.  We didn’t look
> at the % of the CPE base that could be upgraded but noted that some units
> were up to ten years old, with 60-80% of the base typically ISP-provided
> and managed (there was some variability here).
>
>
>
> *Andrew*
>
>
>
> *From:* Eric Orth <[email-masked]>
> *Sent:* 16 November 2020 10:04
> *To:* Tommy Jensen <Jensen.Thomas=[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Add] EER bootstrapping draft scopes
>
>
>
> be updated with a same-IP EER. Does it not make sense to let a single draft
> focus on that scenario that isn't required to also authenticate public
> server bootstrapping?
>
>
>

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 17 Nov 2020 08:34:13 +0100 (CET)

> Il 16/11/2020 21:20 Tommy Pauly <tpauly=[email-masked]> ha scritto:
> 
> Right—if you want to have something that you can prove matches your reference identity, I think there may not be any way to get those guarantees on a network with a forwarder running on a private IP address that can’t ever update DHCP and can’t add its own encrypted DNS support. Arguably, for those cases, you are technically using a resolver (which does little more than forwarding and filtering) that simply has no equivalent encrypted resolver and will never have one. 

This really depends on how you define "equivalent encrypted resolver".

If your definition is functional and user-centred, i.e. "an encrypted resolver that behaves like the unencrypted one that the user is currently using and that is managed by the same entity, but can be reached over encrypted transport", then there will easily be an EER in that case as well.

IMHO it would be useful to break down the discovery discussion and work separately on an agreed definition of EER, rather than having each discovery draft adopt its own slightly different one.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: tirumal reddy <[email-masked]>
Date: Tue, 17 Nov 2020 16:33:24 +0700

On Tue, 17 Nov 2020 at 14:34, Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> > Right—if you want to have something that you can prove matches your
> reference identity, I think there may not be any way to get those
> guarantees on a network with a forwarder running on a private IP address
> that can’t ever update DHCP and can’t add its own encrypted DNS support.
> Arguably, for those cases, you are technically using a resolver (which does
> little more than forwarding and filtering) that simply has no equivalent
> encrypted resolver and will never have one.
>
> If your definition is functional and user-centred, i.e. "an encrypted
> resolver that behaves like the unencrypted one that the user is currently
> using and that is managed by the same entity, but can be reached over
> encrypted transport", then there will easily be an EER in that case as well.
>
> IMHO it would be useful to break down the discovery discussion and work
> separately on an agreed definition of EER, rather than having each
> discovery draft adopt its own slightly different one.
>

Yes, identifying EER is only required for resolver-identified encrypted
resolver discovery (like DEER) and not for network-identified encrypted
resolver (using DHCP/RA extension to provision the name of the resolver).

-Tiru