ADD September 15 2020 Interim 13:00-15:30 GMT

Chairs: Glenn Deen, David Lawrence
AD: Barry Leiba
Note takers: Ben Schwartz (90%), Chris Box (10%)
Jabber Scribe: Andrew Campling

Links:

ADD Datatracker

ADD GitHub

WEBEX

Agenda

Note Well

Agenda bash

Chris Box: Are we considering only the reduced scope of (Martin Thomson's) single use case?
Glenn: I think we are still looking at the full scope. The single use-case proposal discussion on the list hasn't come to closure, so we're still looking at the big picture.

Tommy Pauly: I would suggest talking about the attacker model (#5) before talking about the role of DHCP (#1).
Glenn: Seems reasonable.
EKR: The DHCP question is contingent not only on the authentication model but also on the deployment model. It's common to have user-provided premises equipment between you and the service provider's CPE, and there's no reason to believe it will pass unknown DHCP options. On the use cases question, the authentication question, authentication for the use cases other than "local authentication" are actually relatively straightforward, so I think it would be useful to focus on local authentication.
Glenn: So other than moving #5 up, what else would you like?
EKR: I don't think we have to decide which use cases we're addressing, but I think we should focus this discussion on local authentication, because the other use cases actually have more straightforward authentication stories.

MCR: Agree with EKR but regarding #2 does the client know how to authenticate the network a-priori?
Glenn: I think the working group will need to address that question.

Paul Hoffmann: Related to #5 and other points: what are we assuming for trust anchors? We either have a trust anchor that the user is already holding, or one that they got through some unauthenticated mechanism. That needs to be part of the discussion for #5, because it's completely different if the attacker can push a trust anchor to you.

Paul Wouters: No, you can never know what network you're joining, because it can claim any name.

Note, below #5 was moved to #1.

Welcome & Chairs Statement kigcuvtdfkcgjknbhlrujgcucuierhv

cccccckujunjvdfbcnerivltnucrviikubihhvdvgcjk

Authentication Discussion (topics below)

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??(Formerly #5)

Andrew Campling: In the Uk it's quite common for the ISP to provide a router with wifi etc, so the majority of consumer and SMB users likely do not insert their own network kit (they can and clearly some do, including to substitute the ISP CPE).

Ben Schwartz: We need to address a wide variety of attacker models; some will be secure in some models. We should have a taxonomy of attacks so we can have a shared understanding of which attacks are prevented by a proposed solution.

EKR: It's also reasonably common in the US for ISP's to provide WiFi-capable CPE, but it's also common for customers to plug their own WiFi CPE, e.g. for WiFi mesh. Andrew said "majority", so if 30% of people provide their own CPE, is 70% success? Re: Ben's suggestion, there's certainly going to be a variety of situations, but if we have 25 different threat models and 25 different proposals, then we're going to be here for a long time. What I don't want to see is a pile of solutions each of which is bad in some threat model and none of which occupies a big enough threat model space to be useful.

Tiru: Many network equipment vendors are operating network security service on CPE, such as DNS filtering, so it's actually quite easy for us to update the firmware on these devices to implement whatever option such as DHCP that the working group provides.

Paul Hoffman: Disagree with Ben Schwartz: lots of people have proposed solutions without clearly stated use cases (including myself), with the result that people attack it because it doesn't meet their use case or they support it because if you stretch it a little bit it could reach their use cases. I think we should design based on use cases and attack scenarios. The use case includes the environment. Specifying the environment will lead to "this proposal meets the use case" and "... except for these people" (people using their own wifi, using company wifi that might step on things, etc.). So use case and description first.

Jim Reid: I would suggest that we should try to gather as many use cases as possible, set a deadline (e.g. next meeting or EOY) to come up with a use case, threat model, and potential problems. Once we have that information together, we can say whether each new use case is out of scope, too complicated, don't understand it, etc. At the moment, we've been going in circles a lot, so I think it would help to get the use cases together by a specific date.

Paul Wouters: (1) It seems people are thinking a lot about the ISP scenario, but that leaves out a lot of mobile devices, 5G/4G connections, where the control and security are a lot different. (2) My own CPE that I changed last month came with the password "admin" that allowed me to change everything except the DNS settings, which required me to type in the serial number. So people are trying to make things more secure, but most networks people connect to are untrusted, so we should just give the information and let the connecting entity do what they will with that info. I'd like to have the discovery model focus on delivering information to the user, to let the user make the decision.

Tiru: I think there are two main types of networks: (1) home networks on WiFi with a common password. Users can't tell the difference between the home network and an "evil twin". (2) Enterprise networks with a unique username/password or certificate. The endpoint actually does know it's connecting to the intended organization's network. Those cases are quite different and I think it would help us to identify the threat models to consider each discovery mechanism in one or both of these use cases.

Tommy Pauly: We were talking about the deployment model, but also the attacker model. As a strawman attacker model, consider an attacker that can inject and observe DNS packets, but aren't a full MITM for DHCP. If you're providing all the DHCP and RA, you are effectively the router, so in an untrusted network that's not going to help us at all. And on the other end there are networks with secure provisioning, where we don't have a problem. So if there's anything new to do here, it's related to validating that this new encrypted resolver is related to the thing I got over DHCP. I'd like to hear if anyone disagrees with that attacker model.

Wes Hardaker: We're letting perfect be the enemy of good. Need to build a timeline for a rollout. (1) What can we accomplish now? (2) What can we accomplish longer term? Generally in the IETF we prefer to do one solution, but here we may need two.

Glenn: From this conversation it sounds like we're settling around a couple of core use cases. The in-home use case is one that people are comfortable with, with some sub-cases about various attackers like impersonating the network (although that seems like it would be rare in the wild). But then there are also more complex environments, like cell networks and coffee shops. So when you're commenting please specify which use case you're considering, and tell us which case you think should have priority.

EKR: Unfortunately, I don't think this division works: there's no way to distinguish between home network and a wifi network you just joined. What would you consider success? It's a big difference whether you think that number is 70% or 95%. Also, I don't understand what physical mechanism would allow one to be able to spoof DNS messages but not DHCP: they're both just UDP.

Ralf Weber: In a lot of enterprise environments, switches have guards on which ports are allowed to send DHCP answers. (Maybe home routers too, I don't know.) But then why didn't we just do DHCP last year? For the home case I think it would be OK to do that, because it would be the quickest win.

Erik Nygren: While some of these problems can't be dealt with now, and some are out of scope for ADD, we should not preclude better solutions down the line. Paul Hoffman mentioned methods for establishing root of trust, something through the real world like a QR code or pressing buttons to establish a pairing could help. This might be totally of out scope, but it could of related interest in the case of naming and trust establishment, even if that's post-ADD.

Tommy Pauly: @EKR, yes, if a UDP injection attacker can attack DNS they can attack DHCP, but attacking DHCP is much more "active", and DNS injection is a lighter-weight attack. There are also DHCP guards in some networks. Larger point: if you're already attacking my DHCP traffic, you are already my network provider, and I might as well trust you as much as I trust the network that I don't trust anyway. But I think there are models in which you could attack me in ways where I would be better off choosing the legitimate Do53, vs. an attacker's encrypted DNS server. If you already controlled the unencrypted DNS server, I'm less interested in preventing that attack.

Glenn: Could you clarify the attack you would like to focus on?

Tommy Pauly: Essentially the attacker who controls your configuration entirely (DHCP or RA) -- if they control both the unencrypted and encrypted DNS, then we can't solve that attack without some other form of trust, because they control everything. The attack I'm interested in protecting against is where I would have used a legitimate UDP resolver and I'm being redirected to an attacker encrypted DNS.

Glenn: So the traditional port-53 DNS resolver would be trusted, but the encrypted DNS server is controlled by a nefarioous party.

Tommy Pauly: Correct. If they're operated by the same party, I'm not interested in solving that in this group.

Tiru: I agree with Tommy. The industry has seen ways to deal with DHCP attacks..

Ben Schwartz: Not swayed by arguments against DHCP protection since all such protected networks could also have DNS guards. Distinction not worth consideration. We should focus on fine-grained attacker capabilities. (1) Transient attack upgrading to persistent. (2) Where in the network the attacker is able to act. If you have an injection attacker who is not on your link but on a link upstream of you, they may be able to inject into a cache but can't hijack everything.

Eric Orth: We should consider who we're authenticating. In a lot of use cases the client might know who they want to get this information from (maybe from their ISP), but in other use cases the client doesn't know. But if we just get this information from the network, this isn't an authentication problem, but we still have all these security issues, to avoid giving attackers capabilities they didn't have before. For example, staying within DHCP helps because the network already knows who is permitted to issue DHCP messages and who is not. Otherwise, we might let information through that wasn't supposed to get through.

EKR: I think it's interesting to frame this as Tommy did, as "am I using the DNS resolver I was supposed to be using". So for that even simple opportunistic probing could work. ... The problem with DHCP guards is that clients don't know if DHCP guards are in place or not. If it's insecure, you can't rely on it. It's fine to have mechanisms that might not make the system better but can't make it worse, but not mechanisms that might make it better or worse.

Warren Kumari: (1) In order for an attacker to do DHCP injection they need to be on the same layer 2 network. (2) Almost all wifi networks already have DHCP guard functionality built in. As do most switches. Yes, there's no way for the client to know that but don't let perfect be enemy of good.
Let's solve it for some of the people some of the time.

Tiru: Agree with Warren. One thing I like about DHCP is that in addition to layer 2 protection, we can make it part of a multi-layer solution, like giving it priority but falling back to discovery over DNS (which could be vulnerable to other attacks) if there is no encrypted DNS in DHCP.

Martin Thomson: Interested in what Ben said. I think the vulnerability in SUDN has been highlighted, but if the attacker controls DHCP, so I don't think we should expect anything we build here to have a higher degree of security than the configuration protocol that you're already using.

Paul Hoffman: To mix Tiru + Martin's points: there may be a hierarchy of precedence in what we suggest people use. The user may only have one possibility at any given time. The idea of doing everything in DHCP, or doing everything in the resolver, is probably not good, but we can do more than one, and the working group can provide a prioritized list based on which ones we think are most secure and most likely to work . We don't have to know all of these initially, but if we assume there will be more than one, that's a reasonable way to move forward.

Glenn (not as chair): It might be useful for people who are concerned with specific DHCP attack scenarios to post documented attacks to the list.

Tiru: I think in addition to insecure discovery mechanisms like DHCP, I think we should also consider the work happening in places like RATS, and compare it to the validation performed by Chrome and Firefox on their lists of built-in resolvers. Validation like that could help remove some of the easier attacks.

[13 min break]

Can DHCP play a role in discovery ? What Authentication does the WG feel is needed?

Paul Wouters: Yes
Jim Reid: Yes, it can play a role.
Mike Bishop:
Mark Andrews: ditto
Ralf Weber: Yes
EKR: Maybe
Daniel Migault: Yes
Warren Kumari: Yes
Paul Hoffmann: Yes
Mike Bishop: Yes, but we're not going to get authenticated DHCP, so anything there is no more trusted than what we have today. It can play a role in discovery, but we also need to think about that security model, what security do we actually get? I'm not sure it's where we should start, but it can play a role.
Tiru: Yes
Nicolai Leymann: Yes
Dan Geist: Yes. It may not provide the security level for every circumstance and use case, but if we have a reasonable expectation of security with DHCP today, we should investigate what it would take to do DoT or DoH with DHCP today.
Paul Wouters: Yes
Tommy Pauly: Yes as it's no worse. But shouldn't focus too much time on it as it won't give us the widest benefit short term. Need other mechanisms that are deployable sooner.
Eric Orth: I'm sure it has a strong role, but we should keep in mind that it can't be the only mechanism or the root of all of our mechanisms, so a lot of users can't use it. For Chrome, we don't look at DHCP; we get the configuration from the OS (which gets it from DHCP). DHCP is only going to solve one part of the problem; different clients are goin to have different needs and get their info from different sources.
Glenn (as chair): Clarification on OS/app differences - is psrt of the issue that apps don't see dhcp messages versus OS level discovery where the OS can see dhcp messages?
Eric Orth: I think there's likely some correlation between OSes and applications preferring different mechanisms, but I think it really comes down to the specific client or use case. Some clients just won't want to look at DHCP.
Martin Thomson: DHCP might be an easy win but it's insufficient. Applications may not be able to get it, and the prevalence of forwarders that don't pass DHCP options from upstream. Unless we modify PPPoE and the forwarder box, that info won't reach the client.
Tiru: I think DHCP can be supplemented with other mechanisms like TOFU to allow clients to identify attackers.
Paul Wouters: For most networks, DHCP is as secure as the entire network. You can't spoof your fellow participants on most networks. I can trust the DHCP server as much I trust the network. It's up to the user whether to trust the network with DNS or use it only as a transport for encrypted packets. Whether it's trusted or not is completely independent of the network's decision to send that info in DHCP.
Tommy Jensen: Yes, but information coming over DHCP should not be changing the trust level. Shouldn't generate greater trust than we had before.
Paul Hoffman: Does everyone agree that any use of DHCP will be "insecure"/"unauthenticated"?
Paul Wouters: Do you mean that the "hint" in DHCP is unauthenticated, even if it gets you to an authenticated source?
Paul Hoffman: Yes
Paul Wouters: Yes, there's no point insecuring the DHCP.
Mohamed Boucadair: (in chat) Yes
Jim Reid: I think we need to understand that there won't be a single overarching security model. There might be one for the DHCP use case, and another for other use cases. Otherwise we might be getting back into the trap of trying to find an overarching solution. There will be multiple threat models and multiple solutions, even though we're all working toward the same thing.
Daniel Migault: Considering the responses about whether DHCP should be included, +1 to Eric Orth: I think DHCP is a way to carry some bootstrapping information, but it should not be the only configuration mechanism. It should not be banned from bootstrapping and discovery, but neither should it be the only option.
Glenn: Covered DHCP very well. Now move on to next question.

What is authentication’s role in resolver discovery and validation?

Paul Hoffman: It sounds like "discovery and validation" is being discussed as one thing. That's partly do to me and Puneet's draft. It's now clear to me that these are separate things, so we should discuss authentication's role for these two things separately.

Martin Thomson: I think Ben Schwartz hit on this previously -- if there is any authentication on this process, it present to prevent an attacker from gaining privileges that were not otherwise available to them. In the DHCP case I don't think there's any need for additional authentication, but for solutions that involve talking to the resolver itself, we might need some authentication to make sure that the DNS interactions aren't tampered with.

Ben Schwartz: One way that might help is to think about maintaining certain invariants. DHCP gives us certain properties. One role that authentication can play is to make sure we don't violate those properties. Make sure our solutions can't make things worse. Use cases where client wishes to surface an identity to the user. User would like to know which resolver am I using? If we care to answer that securely we need some authenticated identity for the resolver itself.

Tommy Jensen: Discovery today is unauthenticated. To add authentication implies that someone is advertising a specifc server. But validating that the encrypted server is run by the same entity as the unencrypted server is useful.

Tommy Pauly: I think authentication is for validation, not discovery. What we need to validate is the identity of the resolver that we got from whatever discovery mechanism we have, be it a user input like 8.8.8.8 or DHCP. If the user input is DoH or DoT, we're done. The case that's interesting here is whether the input is an IP address, being able to validate that the encrypted server is equivalent to the unencrypted on that IP address.

EKR: Similar to Tommy, I think the purpose of this discussion is to say that DHCP can tell you whatever it wants. The more interesting problem is where what's been fed into the system is only an IP address. How do you establish that you are in some sense talk to the same people/origin on DoH vs. Do53? I do want to push back on the possibility of having malleability in the URI template. I'm not sure I understand how to validate that, but I do appreciate the idea of having IP SANs in the certificate. It doesn't work for RFC 1918 addresses though.

Ralf Weber: For inband authentication could consider token based. When we talk about DHCP are we including RA and PvD, i.e. all local bootstrap mechanisms?

Paul Hoffman: +1 EKR: When Puneet and I proposed RESINFO earlier, one thing we got beaten up on fairly quickly was that there are no CAs to get certs for IP addresses, which is not true but is approximately true. And you can't get them for RFC 1918 addresses, which is definitely true. This speaks to the 70% solution question. Today, you can get IP certificates from a small subset of CAs, although this is likely to grow. Some OSes have smaller trusted root stores than browsers; some have similar sets. I am OK with a DNS-based solution that excludes resolvers in the private address space. That resolver will also likely have names that aren't in the public address space. I think we have to buy into the idea that private is private and move on.

Vittorio Bertola: You need to define what you're authenticating. In same provider auto upgrade you just need to ensure you're talking to the same entity. Authenticating identity vs Authenticating relationship.

Tiru: I would prefer to use names for authentication instead of IP addresses. ISPs change IPv6 addresses quite often, so it's difficult to acquire certificates from a CA. It's also difficult for the user to verify who the issuer is based on an IP address identity.

Daniel Migault: +1 to Vittorio: The question is not that clear. I believe that the discovery protocol should be based on authenticated information. The purpose of discovery is to be able to proceed to a selection. However, if we have no other options, we may have to rely on non-authenticated information.

EKR: I want to focus on the case where we can't use DHCP for additional provisioning, so all you have is an IP address, from the network or maybe 8.8.8.8 entered manually. There are two scenarios: either you have a database or you do not. If not, you are necessarily exposed to downgrade attacks from an attacker who controls the DNS. Unless you have something like the same-provider auto-upgrade mechanism that Google and MS have used, you cannot defend against a downgrade from an attacker on the local network.

Is authentication to enable identification of resolvers that are associated or affiliated withone another or an organization  needed and is it possible?

Ben Schwartz: DHCP is a term used generally here. We don't need this inside DHCP. Affiliation between resolvers; DHCP is capable of carrying a collection of resolvers. When we are doing in-band post-DHCP upgrade we are wary of an attacker who could divert us to an incorrect resolver. Need to do no worse than DHCP alone. If we are starting purely from an IP address, you have to prove you are equivalent, e.g. by PKI or by operating on that address.

Martin Thomson: +1 except for the last bit, which needs more thought. We only need this association to deal with attacks. Otherwise we're just asking the networks' opinion of what the resolver is, so we don't need to assert an association.

Vittorio: If you reduce it to authentication a relationship, then this suits the leading deployment model. If we could find a way to make this work then we we can step forward more quickly. You can use DNSSEC, TLSA, etc. We should focus on this.

Andrew Campling: +1 to Vittorio: For same-provider auto-upgrade this is particularly important.

Tiru: I think if it's hosted on the same IP address, then this simplifies many things and avoids several attacks.

EKR: To the point that Ben raised about local IP addresses: I have not yet heard of any mechanism that would plausibly allow you authenticate a local IP address resolver, so: what's the value proposition of a way to encrypt that connection if there's no way to authenticate it? We'd have to really flesh out what the attack model is.

Eric Orth: Same IP address is a good mechanism in some cases but I hear there are plenty of situations where it can't be. We still need a way to validate the relationship when they are on different addresses.

Glenn (to both Erics): Have you considered a DoH server hosted on the same IP address but different URLs with different services?

Eric Orth: Same IP address is a proxy for the relationship. All those services are therefore related to the unencrypted resolver.

EKR: Imagine you have two URLs: one answers the question, and the other goes to the attacker. Then you can't allow the attacker to choose the URL. So if you imagine the IP address determines the URL, then it needs to be deterministic. If the URL is discovered over DNS, the attacker can replace the URL with one that goes to them.

Tiru: It's easy for an ISP or security provider to host a server and get a cert. You don't need a new way to obtain certificates for local IP address.

Is Authentication to enable identification of resolvers that are associated or affiliated with another needed?

Is affiliation at the organization level or even between orgs needed? Is it possible?

Any other Authentication aspects that need to be considered?

EKR: Is it important for the client to be able to discern whether it is connected to a securely-discovered or insecurely-discovered DoT/DoH server? A number of these systems have the property that you might upgrade to an encrypted connection, and it is the same person, but you're talking to the attacker either way. So then you have to be careful about doing anything over that connection that you wouldn't have done anyway.

Chairs - close

Glenn: Not planning another interim. We'll have discussion on the list.

Tale: Please provide input into what the structure of our next meeting should look like. Presentation-heavy or discussion-heavy? Interested in feedback.

Andrew Campling: For IETF 109, I wonder if we should request two: one for presentations and one for discussion.

-end of notes-