Subject: [Add] Authentication Sub-topics for Tuesday Interim (homework for Tuesday's meeting)

From: "Deen, Glenn" <[email-masked]>
Date: Fri, 11 Sep 2020 18:51:18 +0000

Hi ADD,

Authentication clearly has emerged as a topic important to the group.   It showed up during the ADD Interim on Sept 10th in both comments and in jabber. Prior to that It has shown up in  drafts, list traffic and GitHub issues.      Coming out of the Interim yesterday it was proposed as the starting topic for the next interim on Tuesday Sept 15.

To help focus and facilitate productive conversation the chairs would like to ask for the group’s help in breaking down the topic of authentication into sub-topics for Tuesday’s interim session.

Here’s a small homework assignment for the next couple of days to help set the Interim agenda:  We ask that ADD participants please take a few minutes and post to this list thread authentication sub-topics you’d like to cover.

To get you thinking on the question,  consider that authentication has come up in a variety of ADD discussions:

      (1) Topic:  the question of can DHCP play a role in discovery which has resulted in many saying “No” since it isn’t authenticated;
      (2) Topic:  the question of authentication’s role in resolver discovery and validation;
      (3) Topic:  the question of authentication to enable identification of resolvers that are associated or affiliated with one another or an organization
      ….

This list is by no means complete and is meant to illustrate a few of the places and contexts the topic of “Authentication” has popped up recently.

Please share what authentication topic, scenario, role, need you believe the ADD group should spend time discussing on the Tuesday agenda.

Please limit discussion on this particular thread to only sharing what authentication sub-topic aspect you’d like to see discussed and not expand into a discussion of the sub-topics themselves.   Yes this all interesting stuff, but the thread can quickly become overwhelming for readers to follow.

So limit, for now, responses to what you’d like to discuss – not the actual technical discussion.

Also, this may prompt some responders to feel like now it is a good time to stray into policy discussions.   Please try to self-regulate and not go there.    ADD is limited to technical mechanisms to do discovery and a means to convey information about the discovered resolvers – and the discussion needs to stay withing those boundaries.

Regards
Glenn Deen & David Lawrence – ADD Chairs

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 13 Sep 2020 16:20:44 -0700

(1) What capabilities are we going to assume an attacker has in the local
discovery model? Do we have *any* candidate design which does anything
useful in those circumstances? If so, what does that design do?
(2) Do we have any secure way to tell clients which resolver the network
wants them to use?
(3) Assuming that we had a secure way to tell clients which resolver the
network wanted them to use, what would we want to say there?

Spoiler alert: I have opinions on the answers to these questions, but that
seems like a topic for the interim.

-Ekr

On Fri, Sep 11, 2020 at 11:51 AM Deen, Glenn <[email-masked]> wrote:

> Hi ADD,
>
>
>
> Authentication clearly has emerged as a topic important to the group.   It
> showed up during the ADD Interim on Sept 10th in both comments and in
> jabber. Prior to that It has shown up in  drafts, list traffic and GitHub
> issues.      Coming out of the Interim yesterday it was proposed as the
> starting topic for the next interim on Tuesday Sept 15.
>
>
>
> To help focus and facilitate productive conversation the chairs would like
> to ask for the group’s help in breaking down the topic of authentication
> into sub-topics for Tuesday’s interim session.
>
>
>
> Here’s a small homework assignment for the next couple of days to help set
> the Interim agenda:  We ask that ADD participants please take a few minutes
> and post to this list thread authentication sub-topics you’d like to
> cover.
>
>
>
>       (1) Topic:  the question of can DHCP play a role in discovery which
> has resulted in many saying “No” since it isn’t authenticated;
>
>       (3) Topic:  the question of authentication to enable identification
> of resolvers that are associated or affiliated with one another or an
> organization
>
>       ….
>
>
>
>
>
> This list is by no means complete and is meant to illustrate a few of the
> places and contexts the topic of “Authentication” has popped up recently.
>
>
>
> Please share what authentication topic, scenario, role, need you believe
> the ADD group should spend time discussing on the Tuesday agenda.
>
>
>
> Please limit discussion on this particular thread to only sharing what
> authentication sub-topic aspect you’d like to see discussed and not expand
> into a discussion of the sub-topics themselves.   Yes this all interesting
> stuff, but the thread can quickly become overwhelming for readers to
> follow.
>
>
>
> Also, this may prompt some responders to feel like now it is a good time
> to stray into policy discussions.   Please try to self-regulate and not go
> there.    ADD is limited to technical mechanisms to do discovery and a
> means to convey information about the discovered resolvers – and the
> discussion needs to stay withing those boundaries.
>
>
>
> Regards
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: tirumal reddy <[email-masked]>
Date: Mon, 14 Sep 2020 13:20:25 +0530

On Mon, 14 Sep 2020 at 04:51, Eric Rescorla <[email-masked]> wrote:

> discovery model?

We can start with RFC 3552 and evaluate if a weaker threat model is
required.

> Do we have *any* candidate design which does anything useful in those
> circumstances? If so, what does that design do?

Yes, secure discovery is possible in certain deployments (e.g., Enterprise,
VPN) but not in networks with common passwords for WiFi
authentication/Opportunistic Wireless Encryption (susceptible to passive
and active attacks).

>> Authentication clearly has emerged as a topic important to the group.
>> It showed up during the ADD Interim on Sept 10th in both comments and in
>> To help focus and facilitate productive conversation the chairs would
>> like to ask for the group’s help in breaking down the topic of
>> authentication into sub-topics for Tuesday’s interim session.
>>
>>
>>
>> Here’s a small homework assignment for the next couple of days to help
>> set the Interim agenda:  We ask that ADD participants please take a few
>> minutes and post to this list thread authentication sub-topics you’d like
>> to cover.
>>
>>
>>

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 14 Sep 2020 19:48:08 -0700

Hi Ekr,

Some thoughts in response, prior to the meeting (so I don’t forget due to the early hour):

My sense is that we need to look at attackers that are limited to not being able to act as the network provider or router themselves—specifically, assume the attacker is not the one providing DHCP or sending RAs. If we consider such an attacker who can spoof or inject packets to a client, I think there are some security benefits that a discovery can provide. 

If what I want to discover is a DoH resolver that is equivalent to the Do53 address I already know (maybe by DHCP, maybe something else), I’d want a mechanism to guarantee that:
a) I’m no worse off sending my queries to the DoH server (I trust it just as much as I did the Do53 resolver, however much that was based on my provisioning mechanism)
b) My queries cannot now be modified or observed by other entities on my network or path

I think this much is doable in some deployment models. For example, using a model like Comcast’s DoH deployment, if the DoH server’s TLS cert includes in its SAN list the address of the Do53 resolver provisioned by the network, I think we’d get the two benefits listed above. (This is what Tommy Jensen proposed in https://www.ietf.org/id/draft-pauly-add-resolver-discovery-01.html#name-discovery-of-doh-capabiliti)

The set of resolvers that are accepted in this manner could also be restricted to a known list or a publicly available list if we want the additional guarantee that a given resolver is “official” and not just some server that managed to get a cert that covered a particular address.

What might not be possible, on the other hand, is to usefully authenticate a deployment model where the resolver or forwarder is some private/local address that’s running on a router itself–unless this is a managed network or managed device that has some out of band mechanism to trust or configure resolvers (at which point we don’t need discovery mechanisms). I think the case of trying to find an equivalent and trusted resolver to the one running on 10.0.0.1 on my router ends up being indistinguishable from an attack scenario. But these scenarios likely aren’t worth solving this way anyhow—if the DoH server isn’t on my router itself, but hosted in the ISP network, the network would do better to provision the address of that ISP server instead of a local address; and if I really have a DoH server running locally, the router would presumably be able to upgrade to be able to provision the DoH information directly in DHCP/RA/PvD.  

Best,
Tommy

> On Sep 13, 2020, at 4:21 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> (1) What capabilities are we going to assume an attacker has in the local discovery model? Do we have *any* candidate design which does anything useful in those circumstances? If so, what does that design do?
> (2) Do we have any secure way to tell clients which resolver the network wants them to use?
> (3) Assuming that we had a secure way to tell clients which resolver the network wanted them to use, what would we want to say there?
> 
> Spoiler alert: I have opinions on the answers to these questions, but that seems like a topic for the interim.
> 
> -Ekr
> 
> 
>

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 15 Sep 2020 12:00:45 +0200

Moin!

On 15 Sep 2020, at 4:48, Tommy Pauly wrote:
[…]
> What might not be possible, on the other hand, is to usefully 
> authenticate a deployment model where the resolver or forwarder is 
> some private/local address that’s running on a router 
> itself–unless this is a managed network or managed device that has 
> some out of band mechanism to trust or configure resolvers (at which 
> point we don’t need discovery mechanisms). I think the case of 
> trying to find an equivalent and trusted resolver to the one running 
> on 10.0.0.1 on my router ends up being indistinguishable from an 
> attack scenario. But these scenarios likely aren’t worth solving 
> this way anyhow—if the DoH server isn’t on my router itself, but 
> hosted in the ISP network, the network would do better to provision 
> the address of that ISP server instead of a local address; and if I 
> really have a DoH server running locally, the router would presumably 
> be able to upgrade to be able to provision the DoH information 
> directly in DHCP/RA/PvD.
I think upgrading via the CPE is worth doing, as even a caching 
forwarder has benefits. The solutions you provide (DHCP/RA/Pvd) don’t 
provide authentication. Does that mean you are ok to accept 
unauthenticated DoH URIs from these solutions, but not from an CPE/DNS 
based auto upgrade?

So long
-Ralf
——-
Ralf Weber

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 15 Sep 2020 14:43:29 +0200 (CEST)

>     Il 15/09/2020 04:48 Tommy Pauly <tpauly=[email-masked]> ha scritto:
> 
>     What might not be possible, on the other hand, is to usefully authenticate a deployment model where the resolver or forwarder is some private/local address that’s running on a router itself–unless this is a managed network or managed device that has some out of band mechanism to trust or configure resolvers (at which point we don’t need discovery mechanisms). I think the case of trying to find an equivalent and trusted resolver to the one running on 10.0.0.1 on my router ends up being indistinguishable from an attack scenario.
> 
What would be the security problem if 10.0.0.1 via Do53 received a "resolver discovery" query, forwarded it to the main resolver, received a DNSSEC-signed response, forwarded you the response, and the response included both a DoH URI and a TLSA record that the DoH resolver's certificate has to match?

>     But these scenarios likely aren’t worth solving this way anyhow—if the DoH server isn’t on my router itself, but hosted in the ISP network, the network would do better to provision the address of that ISP server instead of a local address;
> 
It has been explained that this would as a minimum require firmware/configuration upgrades on millions of CPEs, and as a maximum be impossible because CPEs have the forwarding configuration hardwired or are out of support by the manufacturer. Perhaps in 5-10 years, not now.

>     and if I really have a DoH server running locally, the router would presumably be able to upgrade to be able to provision the DoH information directly in DHCP/RA/PvD.  
> 
A DHCP extension to advertise a DoH URI was proposed at an IETF meeting over a year ago. It was rejected as too insecure, but if that assessment changes, of course it could be considered.

--

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

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 15 Sep 2020 05:45:08 -0700

> On Sep 15, 2020, at 3:01 AM, Ralf Weber <[email-masked]> wrote:
> 
> Moin!
> 
> I think upgrading via the CPE is worth doing, as even a caching forwarder has benefits. The solutions you provide (DHCP/RA/Pvd) don’t provide authentication. Does that mean you are ok to accept unauthenticated DoH URIs from these solutions, but not from an CPE/DNS based auto upgrade?

That’s a good question to raise. One difference is that spoofing the provisioning protocol means the attacker has to be a bit more involved in order to pull off an attack without detection—you can become a man-in-the-middle and act as the effective router, which is a different level of attack than injecting a DNS response to convince a device to use some arbitrary DoH server of the attacker’s choosing. (There are also some anti-spoofing features like RA-guard which could make it harder to attack than injecting DNS responses.)

This is largely based on the choice of attacker model I described at the top of my email—to consider attackers who aren’t a man-in-the-middle for DHCP, which means your Do53 is already a problem. A different choice of attacks to prevent can lead to a different set of acceptable solutions. However, I’m not sure which models would support unauthenticated upgrade for a CPE based resolver. 

Best,
Tommy

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 15 Sep 2020 22:54:01 +1000

On Tue, Sep 15, 2020, at 22:43, Vittorio Bertola wrote:
> A DHCP extension to advertise a DoH URI was proposed at an IETF meeting 
> over a year ago. It was rejected as too insecure, but if that 
> assessment changes, of course it could be considered. 

I always wondered about that.  Under what assumptions was it rejected?

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 15 Sep 2020 17:37:28 +0200 (CEST)

> Il 15/09/2020 14:54 Martin Thomson <[email-masked]> ha scritto:
> 
>  

This is the draft:

https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00

It was two years ago and I don't remember well, but I think it was a fundamental objection like "we have decided that DHCP is insecure and we will not extend it any more".

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

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 15 Sep 2020 18:03:39 +0000

Hey Vittorio,

> What would be the security problem if 10.0.0.1 via Do53 received a "resolver discovery" query, forwarded it to the main resolver, received a DNSSEC-signed response, forwarded you the response, and…

The problem is there's no name associated with the original Do53 server. The client, in order to trust the DNSSEC claim, needs to know the name being signed in advance. Otherwise, an attacker can intercept and replace the DNSSEC-signed DoH URI and TLSA record with their own DoH server information, correctly DNSSEC signed.

A client in this scenario can't distinguish between valid signed data for "doh.exmaple-isp.com" and "doh.example-attacker.com". Realistically, this will complicate any attempt to validate ownership between a non-public Do53 IP address and a DoH server. Until the network authentication problem is more generally solved, I don't think authenticating local DNS servers is a good use of the WG's time.

Thanks,
Tommy

================================================

The latest in Windows Internet Protocols:

  Native gRPC support: https://aka.ms/grpcblogpost

  DNS over HTTPS: https://aka.ms/dohblogpost

________________________________
From: Add <[email-masked]> on behalf of Vittorio Bertola <vittorio.bertola=[email-masked]>
Sent: Tuesday, September 15, 2020 5:43 AM
To: Tommy Pauly <tpauly=[email-masked]>; Eric Rescorla <[email-masked]>
Cc: ADD Mailing list <[email-masked]>; Deen, Glenn <[email-masked]>
Subject: [EXTERNAL] Re: [Add] Authentication Sub-topics for Tuesday Interim (homework for Tuesday's meeting)

--

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

---

From: Christian Huitema <[email-masked]>
Date: Tue, 15 Sep 2020 11:40:50 -0700

On 9/15/2020 11:03 AM, Tommy Jensen wrote:
> > What would be the security problem if 10.0.0.1 via Do53 received a
> "resolver discovery" query, forwarded it to the main resolver,
> received a DNSSEC-signed response, forwarded you the response, and the
> response included both a DoH URI and a TLSA record that the DoH
> resolver's certificate has to match?
>
> The problem is there's no name associated with the original Do53
> server. The client, in order to trust the DNSSEC claim, needs to know
> the name being signed in advance. Otherwise, an attacker can intercept
> and replace the DNSSEC-signed DoH URI and TLSA record with their own
> DoH server information, correctly DNSSEC signed. 
>
> A client in this scenario can't distinguish between valid signed data
> for "doh.exmaple-isp.com" and "doh.example-attacker.com".
> Realistically, this will complicate any attempt to validate ownership
> between a non-public Do53 IP address and a DoH server. Until the
> network authentication problem is more generally solved, I don't think
> authenticating local DNS servers is a good use of the WG's time.

But is that problem even solvable? The chain of event seems to be:

1) Connect to some random network

2) Get the IP address of the local Do53 resolver using DHCP

3) Infer the identity of the equivalent DoH resolver

4) Connect to said resolver

5) Verify that it is equivalent to the Do53 resolver

Step 5 checks that the identity verified by TLS identity matches the DoH
identity discovered in step 3. Thus, it cannot be more secure that the
process used to infer that identity. In the case of "random networks", I
don't see how that can be secured. You might push it one layer down if
the L2 network is somehow configured, and for example associate a DoH
identity with a Wi-Fi network ID, but then we are not considering random
networks anymore. Do we want to replace "random network" with "well
identified network"?

-- Christian Huitema

---

From: tirumal reddy <[email-masked]>
Date: Wed, 16 Sep 2020 15:13:07 +0530

On Tue, 15 Sep 2020 at 21:07, Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> It was two years ago and I don't remember well, but I think it was a
> fundamental objection like "we have decided that DHCP is insecure and we
> will not extend it any more".
>

DHCP/RA extension can be used to convey the domain name of the resolver
(see https://tools.ietf.org/html/draft-btw-add-home-08#section-6) and the
protocols (DoH/DoT/DoQ) it supports. If the DNS server supports DoH, the
client can establish the DoH session (validate the server certificate as
usual) and use a well-known URI to retrieve the list of DoH services (for
example using RESINFO). It avoids the problem that an large list of URI
templates may cause the size of an DHCP/RA to exceed the link MTU.

-Tiru

---

From: Tommy Jensen <[email-masked]>
Date: Mon, 21 Sep 2020 18:08:33 +0000

Hey Christian,

I think scoping the problem to "well identified network" seems reasonable.

Do we need a protocol for this case? If I can get the network's DoH template from the same source I got the SSID from, then they're equivalently trusted. For enterprises, that can reuse existing network profile configuration mechanisms. For coffee shop / airport / hotel style networks, that can be printed on the same sign/card as the SSID/password (or the captive portal page as part of use terms?).

Perhaps this is exactly what you meant and I'm just being dense.

Thanks,
Tommy

________________________________
From: Christian Huitema <[email-masked]>
Sent: Tuesday, September 15, 2020 11:40 AM
To: Tommy Jensen <[email-masked]>; Vittorio Bertola <[email-masked]>; Tommy Pauly <[email-masked]>; Eric Rescorla <[email-masked]>
Cc: ADD Mailing list <[email-masked]>; Deen, Glenn <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: Authentication Sub-topics for Tuesday Interim (homework for Tuesday's meeting)

Step 5 checks that the identity verified by TLS identity matches the DoH identity discovered in step 3. Thus, it cannot be more secure that the process used to infer that identity. In the case of "random networks", I don't see how that can be secured. You might push it one layer down if the L2 network is somehow configured, and for example associate a DoH identity with a Wi-Fi network ID, but then we are not considering random networks anymore. Do we want to replace "random network" with "well identified network"?

-- Christian Huitema