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

["Deen, Glenn" <[e-mail]>]

Tommy,

There’s a number of interesting points you raise here,

As they say on the Jeopardy gameshow on TV,  Can you please phase these each in the form a question  - or at least a requirement that solutions can be evaluated against?


Regards
Glenn

On 9/14/20, 7:48 PM, "Tommy Pauly" <[e-mail]<mailto:[e-mail]>> wrote:

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<https://urldefense.com/v3/__https:/www.ietf.org/id/draft-pauly-add-resolver-discovery-01.html*name-discovery-of-doh-capabiliti__;Iw!!CQl3mcHX2A!Xmr8G5GK6rB29BarFUTf01NwhCe0ncVvDbZruCRLN1yJ5WtI_W7tyyXzLcZqohWf1A$>)

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 <[e-mail]> 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



On Fri, Sep 11, 2020 at 11:51 AM Deen, Glenn <[e-mail]<mailto:[e-mail]>> 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.

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
--
Add mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/add<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!CQl3mcHX2A!Xmr8G5GK6rB29BarFUTf01NwhCe0ncVvDbZruCRLN1yJ5WtI_W7tyyXzLcan2Y3raA$>
--
Add mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/add<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!CQl3mcHX2A!Xmr8G5GK6rB29BarFUTf01NwhCe0ncVvDbZruCRLN1yJ5WtI_W7tyyXzLcan2Y3raA$>