ADD Adaptive DNS Discovery

Group: Adaptive DNS Discovery Responsible AD: Barry Leiba

Chairs: David Lawrence, Glenn Deen

IETF109 ADD WG draft Session Agendas

ADD Chairs & AD

Session link, minutes, jabber

IETF 109 ADD Session Times

ADD has 2 sessions during IETF109: Session 1 is Monday November 16; Session 2 is Friday November 19

Session 1: Monday, November 16 2020 (UTC+7)

Time in different zones: * ICT: 14:30-15:30 (UTC+7) IETF Agenda TZ and Bangkok meeting "location" time * IST: 13:00-14:00 (UTC+5.5) * CET: 08:30-09:30 (UTC+1) * UTC: 07:30-08:30 (UTC+0) * EST: 02:30-03:30 (UTC-5) * PST: 23:30-00:30 (UTC-8) Note: This is Sunday November 15 in PST

Session 1 Agenda




draft-pauly-add-deer-00 15 min Slides

Glenn: Please keep questions focused on all but the concept of equivalency. EKR: Thinking about this name version .. It seems like it has the same problm and the ? version. The attacker can still attack you. Tommy: I learn about It seems like this is an attack that could happen independent. It can happen with any type of discovery. That's a more general property of not haing a hard-coded address with your resolver name. EKR: Agreed. Martin Thomson: I'm not clear on why you have multiple reference identities. If you discover something by DHCP, you look for the domain name and get an IP address. Why do you need all the extra stuff from the SVCB record? Tommy: So DHCP gives you and you get URI. You should validate domain and IP address. We should clarify. Martin: Yes. Jonathan Reed: It's often the case people have configured more than one resolver. Also, we can't have certs about derived IP addresses. It seems ok for it to start 853 without catching the IP address? Tommy: We just talk about the mechanism. For private IP we still support opportunistic. But beyond supporting same server there's not much to check. There's 2 ways frward for resolver on private IP. They either support encrypted DNS there or we support providing a name that they can then go out and search on. Ben Schwartz: Talking about what EKR mentioned. Attacker can make your IP different. I think we should consider this out of scope. Client IDs are not authenticated. The whole web has this problem. If we want security protocols that can prove the client ID from vantage of serer we should come back to that later. Let's not turn SVCB into reference identity. The same IP restriction is interesting. It's based on threat model I haven't heard stated exactly. I'd like to think about that.I think this comes down to transient attack upgrade? Tommy: Yes. David Schinazi: Our Chrome team looked at auto IP upgrading to same IP. But we find most resolvers are configured in RFC1918 (private IP) space. Does ths do anything for that? Tommy: In thise networks -- how are they adding support for encrypted DNS? David: They aren't. Most users don't upgrade router firmware so they won't get encrypted DNS on the router. Tommy: We don't think there are solutions that don't open up another attack. David: I think this is and will remain the majority of users. Tommy: We're starting by trying to find a solution for some. David: OK, I think that's fine and we can build from there. EKR: The semantics of your opportunistic is to go to IP blah. But what David is talking about is case where if you just try connecting to that IP it won't work. So what happens if you just try TLS to that private IP router? Tommy: Our opportunistic proposal here is using opportunistic name. That could still be filtered out by network. EKR: Is there some mechanism where what you have is basically a dumb forwarding resolver to one of the large resolver farms that would take DoH if you had it. Maybe we should start with more restrictive use case. Tommy: When we talk about equivalency, would they really be equivalent? They sometimes have other features that will be skipped. I think maybe you need to change original resolver in that case. EKR: Do you have metrics? Tommy: No it would probably be useful to collect metrics. Tommy: Some will give non-private IP addresses, like Comcast. Tiru Reddy: -- does not hear us -- Martin Thomson: Maybe case they're talking about with private IP sort of works. You make query to special use domain and you get a response. We're looking at case where you don't have reference ID. So you don't get some of the protections. For cases I'm interested in where we want DoH server for IP network outside of LAN is ok. Tommy: Relax checks? Martin: You don't have reference identity. It's weaker than other model where you accepted DHCP is insecure. Tommy: Yes, it may create an encrypted channel to someone who may be an attacker. Previously they had to continually attak you. With this, they only need to do it once. Martin: I was just saying there are some identities we might be willing to go to because we know a priori that we trust certain resolvers. David Schinazi: I want to provide numbers that Chrome sees. Only 15% of users worldwide have non private IP addresses. Of those 15%, half map to known DoH servers. It sounds like we're building a solution for small number of users. I think you could do something that would let you go through your router to an ISP server that supports DoH. So maybe decreasing security here increases security. Tommy: Right, so we could have different rules for when you have a private IP address. That's different from if you have and making sure that can't be attacked. Ben Schwartz: I've heard ways to loosen matching requirement based on 1918 address. I've heard maybe encrypted resolver is on list of known well-behaved resolver. But I think also maybe client knows more about network it's on. If client can assess network and see network has no RA guard. Maybe then it can be open to other means. Tiru: We're using acme and then endpoint can still use DoT forwarder from the router. But that will only be visible to endpoint connected to home. But our draft is ... It's not clear if we move to DNS based discovery how that problem would be solved. EKR: Those are terrible numbers David gave. f we aren't solving problem of people with 1918 resolvers then we aren't solving much. I think we really need a problem definition at this point. David Lawrence: I would agree and we're working on that. Any comments from people on jabber? No.


Discuss Concept of Equivalent Resolvers found in Draft-pauly-add-deer-00 and draft-box-add-requirements-01 Slides

Martin: I think this is mostly ok. My understanding is whatever resolver you have, assume you trust it and can communicate to it through means that are secure and use it to securely get to a resolver when you're on an unsecure network. EKR: I'm not ok with this. It can send you to DNS server operated by attacker. I'm sending comments to list. Ben: You need to talk about temporal component. Not just whether they are equivalent, but whether they will stay equivalent. Ted Hardie: If someone tries to test whether this is still equivalent. Unless they're serving out of same cache, they can get different answers just because of the rest of the system changing over time, in a way that is not a function of the resolver. I think we need to write down exactly what is the same to understand what the client can actually be sure about. There's not much the client can trust. Mike Bishop: I think this is a better definition of what equivalecy should be. There's more complexity than saying it provides the same service. DKG: Looking at response messages is extremely weak. There are a lot of factors beyond just what you get. EKR pointed out server that sends to Twitter. But also linkability, etc. Whether client does client-side authentication...

Glen Deen: Note: The session had a Meetecho failure which caused everyone to drop and have to rejoin.

Planning & Wrap up

Glenn: We'll pick up on Friday here where we left off. David Lawrence: Those who were still in queue, please make note so you can remember what you wanted to say.