IETF112 ADD Adaptive DNS Discovery Meeting

ADD WG Information, Meeting Materials, Links

Materials, Charter, Documents

• ADD WG General Info
• ADD GitHub Repositories
• ADD Documents, Drafts and I-Ds

People

• AD: Éric Vyncke
• Chairs: Glenn Deen, David Lawrence
• Scribe: Watson Ladd (with help from Barbara Stark, and Martin Thompson)

Session link, minutes, jabber, materials

• Meetecho Link remote participation
• Meeting Minutes
• Meeting Chat
• IETF 112 ADD Presentions

IETF 112 ADD Session Times

• Monday November 8, 2021, 16:00-18:00 UTC

ADD Agenda

Welcome

• 5 minutes
• NOTE WELL
  • And the note really well: be kind
• Scribe selection
  • Martin Thomson and Watson Ladd
• Agenda bashing
• Welcome from chairs

Chair slides: ADD 112 Agenda Slides
Agenda was not bashed. It remained intact.

Working Group Drafts Updates

1. Discovery of Designated Resolvers (DDR)

• draft-ietf-add-ddr
• 15 minutes + 20 minutes Q&A
• Tommy Pauly presenting
• Slides: draft-ietf-add-dnr
• Changed name of "authenticated mode" to "verified mode"
• Open PR looking for clarifying questions pr 43, "What is actually being verified?"
• Change proposed: If IP proposed, verify cert covers IP. If name covered, check name is covered in cert
• Vinny Parla: Is it resolver IP and IP to bootstrap discovery?
• Tommy: Yes; if told over DHCP look for 8.8.8.8, check that cert has 8.8.8.8
• EKR (Eric Rescola): Does result have to be on cert? Hear "look at 4.4.4.4". A: used to, now check for thing you started with. ReQ: Just like CNAME. authority needs to match what was configured (for example, if the server allows the connection to the IP, then steers using Host: or :authority, then you might have an attack)
• Clariy that the resolver.arpa name is not the one you start with so should never be in the SNI or DoH request authority.

1.1 Focus topic: DDR Pull Request 43

• DDR PR #43: Cert checks only IP address, clarify server name (PR #43)
• • Last question, probably most controversia: intermediate target name. Should I be able to use something other than IP as name in DoH URI?
• Example: 8.8.8.8, get dns.google, resolve to IPv6 2001:4860::8844, now what SNI to send/use for authority?
• Martin Thomson: Don't use any of the intermediate stuff: while names are there, not something in protocol
• Tommy: some APIs don't let you separate DNS name from name on cert
• EKR: name based virtual hosting. One thing for 8.8.8.8 another for safe-lookup.google.com. On path can shift resolutions.
• Tommy Pauly: DOH path also exists for this problem. Only thing we verify is quad-8. Attacker could change that initial option. Seems like banning authority with name is to far
• EKR: Security property. What is configured determines what you get. Anything not there can be changed by attacker: would here be path and host. E.g. CDN that uses Host: for steering. [EKR: attempting to clarify post-hoc. What if you have a situation where a DoH server is co-located with a hosting system, e.g., "doh.example.com" and "ekr.example.com" and the CDN just steers based on Host: header. So what I do is I stand up a DoH server on "ekr.example.com" that produces lying responses. Then I arrange for your SVCB record to have the name "ekr.example.com" and I have persuaded the client to accept responses from my invalid server.]
• Ben Schwartz: This requires both IP and targetname on same cert. Client verify the SCVB authority?
• Tommy Pauly: no just the address
• Ben: Issue with HTTPS authority vs transport. Potentially requires servers to use real names in targets. Violation of HTTP semantic rules, because HTTPS URLs are only valid for authorities that have proven crypto control. Also requires servers to use real names in their target names.
• Erik Nygren: lots of anxiety, not right answer. Attacks raised added onto it. SNI critical. Lots of multihosting. Client must send SNI that matches what it gets. SNI only allows names not IP addresses.
• Tommy Pauly: no SNI
• Erik: Need SNI because multitenant. Eg. Google Frontend. Lots of similar services. Would like to avoid different IPs to demux.
• Tommy: but the resolvers already get IP addresses
• Erik: need to look to examples to see if they work
• Watson Ladd: I think that this proposal is the best you can do. With SNI you are going to have to send it to the same IP that the name resolves to. You are looking for a way to reach something that you only know by IP.
• Tommy Jenson: An alternative approach would be to document security consdierations and not allow servers to branch based on authority information. This isn't requiring name to be used, just allowing it. Host is surprising to omit, but authning IP address for DDR. Confirming solid but over HTTPS. Want whoever gave me DDR to tell me name to use. HTTPS will authenticate hostname. Not branching is wise.
• Tommy Pauly: allowing puts requirement on all resolvers
• Ben Schwartz: DDR records aren't changing here, just what the client does. Clients not branching on authority, per EKR can't be forbidden. Ideal allow IP in SNI. Right now 8.8.8.8:443 gives cert covering the IP address, not same cert as google.com:443. Virtual hosting just not securable here.
• DOHpath attacker controlled in security considerations, welcome improvements.
• Tirumaleswar: We do have an embedding of IP to arpa
• EKR: Lots of TLS things we could do, flags, SNI extensions, outside this wg.
• Apparent conclusion: client sends IP address as authority, not name. Will send to list, update PR, then ready for last call

2. DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR), Dan Wing

• draft-ietf-add-dnr
• 5 minutes + 5 minutes Q&A
• Dan: Authors think ready for last call, were holding off to make sure aligned with DDR and do DDR/DNR at same time.
• Chair: Plan of doing them together makes sense. We'll likely do it that way.

Other Drafts

3. Discovery of Designated Resolvers in the Presence of Legacy Forwarders, Ben Schwartz

• draft-schwartz-add-ddr-forwarders
• 10 minutes + 5 minutes Q&A
• Slides: DDR and Legacy Forwarders
• Scenario: client has a forwarding resolver that sends to a full-service resolver that supports encrypted DNS
• Can client opportunistcally upgrade?
• Active adversary can always win
• DDR as-is excludes forwarder case because it can only upgrade on the direct client-to-resolver link. But lots of internet users stuck behind forwarders.
• Idea: client relaxes restriction on switching to a resolver identified by a private IP address (which will be in cert)
• Issues: usage restrictions, blocklists
• Neil Cook offered to provide examples of where parental controls were implemented; but noted that these might be addressed in the same way as other interception (block resolver.arpa)
• How would it interact with forensic logging?
• Split horizon issues
• Caching
• "Interposable names". Keep track of the small number of these interventions to avoid breaking them
• Seeking adoption
  • No less secure than DDR
  • Describes advantages and disadvantages
  • Mitigations of some problems. Makes no specific policy recommendations
• Vinny: filtering only matters if forwarder is providing the service. At resolver not a problem.
• Barbara Stark: hope we can do this even though it might not get through last call. The discussion itself is important.
• Tirumaleswar: Good starts, lots of security considerations. If routers aren't geting updates, sounds like a big problem with security
• Martin Thompson: people will do this, need harm reduction. Benefits users. What is the thought behind possibly not being able to get through last call?
• (Barbara responding in chat: not enough interest from implementors)
• Ray Bellis: RFC 5625 on dns proxies found on home gateways. Most proxies aren't true forwarding resolvers, just simple app gateways that don't really do DNS, they just rewrite headers. Upstream might not even be knowable.
• Andrew Campbell: CPEs don't get replaced nearly often enough: decades lifetimes. Long-term problem, and it is 85% of market.

WG Adoption Considerations

4. Split-Horizon DNS Configuration

• draft-reddy-add-enterprise-split-dns
• 5 minutes + 15 minutes Q&A
• Slides: draft-reddy-add-enterprise-split-dns
• Reques for adoption, but there's been low list interest for the path forward
• Dan Wing presenting
• Split horizon: beyond enterprise, better handling for geographic also
• Added example message flow and ASCII art
• Do we want to solve a problem?
• Is this mechanism reasonable, to ask a public resolver for who owns the domain and ensure a match with the previously fetched info.
• Glenn: one note, if it is adopted it will get renamed. People aren't happy with "enterprise".
• Paul Wouters: confused about public resolver and split horizon. Public is public. Split is split. So how does public server get private domain?
• Dan: doesn't exist, and can identify as internal-only. Or its split that does exist answers different. Then look for match
• Paul: worried about typosquatting
• Dan: intended to prevent typosquatting
• Glenn: Please include additional security text about the typo protections
• Dan: Will do
• Watson: doesn't make sense. Public resolvers won't work, if talking to private get the split view. Split DNS bad.
• Dan: So you're saying there isn't a real problem to solve?
• Watson: [Essentially yes because of the context of private resolution.]
• Tommy: real problem: not sure about solution. Where does this belong? Bigger than ADD, authority over resources, very interesting problem could use all sorts of things and could have a whole WG for it. PVDs in INT area, need some of that audience.
• There can be easy ways to work around purely private domains, but we experience a lot of pain with one situation in icloud private relay service. If resource doesn't exist, try locally: works fine. Biggest problem has been handling dual-facing resolving servers that respond to the same differently depending on inside vs outside. Harder problem than this doc has so far.
• Glenn: so you're saying do the work but not in ADD?
• Tommy: Sort of. We need to bring in more expertise, to look at how to do discovery of authority on the network.
• Ben Schwartz: Broadly supportive of this draft. View it as harm reduction. I'd like to ax split DNS. If we accept we can't kill it off then we need better guidance on proving to network that they are getting valid answers that they need and are secure and appropriate.
• Two separate solutions: for names that don't exist, means nonexistent TLDs.
• Worth focusing on hard case: name exists both public and private, want users to resolve differently.
• Mention of public resolvers is practical but raising people's hackles and not necessary to include. Draft based entirely on dnssec. If you say auth between name and local resolver is DNSSEC-based. If people want to delegate validation to a trust third party, that's their buisness.
• EKR: a problem I wish wasn't. Agnostic on ADD or some other group. Let ADs worry about that. Agree with Ben that nonexistence is less interesting then multiple answers. Off-brand for me to say this, but DNSSEC is right answer for this. Can stuff into PVD even
• Andrew: some comments saying don't do this, but people already do this. Need a solution. Common practice in enterprises and oher use cases. We need to solve because otherwise encryption bypasses. Let's adopt it.
• Vinny: The problem with nxdomain fallback has been leaking names out of the enterprise. We put lots of work on not using resolvers outside network in VPN clients to avoid that leaking. Need to solve generically.
• Éric Vyncke: Lots of interest. ADD or somewhere else. Fits ADD charter, so good. But may want to check with dnsops and INT area chairs. ADD aware of the problem so should sit. Call for adoptions only now; so issues can be sorted later
• Wes Hardaker: Adding some historical context. Been confronting these issues for many years. Check RFC 8244. We're taking a head off the hydra. Split DNS is a giant thing, much larger than this group. Can't really do it with just the ADD wg. Here be dragons.
• Dan: Yes, the 2007 DNSSEC split horizon draft was great. I didn't really dig into why it was abandoned, but gave good scenarios to evaluate against.
• Wes: I can answer the abandonment. WG couldn't come to agreement that it was a good thing to do.

5. Discovery of Encrypted DNS Resolvers: Deployment Considerations

• draft-boucadair-add-deployment-considerations
• Slides: Discovery of Encrypted DNS Resolvers: Deployment Considerations
• 5 minutes + 15 minutes Q&A
• Not specific to DNR, so pulled it out
• Maintained and unmaintained ISPs, fixed and cell
• Glenn as chair: we do have an informational doc sort of like this in our deliverables. This is a start on that bigger informational one. On path is to start work on that one, take useful pieces out of this one
• Andrew: useful to write down requirements lots of different assumptions
• EKR: not even remotely what is in charter. Charter is about mechanism to detect specific network environments and fits previous presentation better. Until someone starts doc this isn't that. Material here that we will bikeshed over. Don't want to spend next two years on that. Document is fine as an I-D but doesn't need to be WG item
• Neil Cook: Kind of surpised by that feedback; thought this is uncontroversial. Lists how ADD can be used
• EKR: thought I could ignore the details because it wasn't adopted. Remember reading is and not being happy
• NC: a bit prescriptive in places, could be better without that
• Tommy: Largely agree with ekr. Why not make this part of the document that we have to deliver? Start work on that deliverable, then can see what other stuff here makes sense in that.
• NC: I can see the idea of being part of the larger document, but I don't get the point that it isn't that relevant to ADD. It does cover something on topic in ADD, though a narrow subset. Think it's relevant to the working group and addresses the most common way that people access the Internet.
• Tommy: could be referenced by other drafts. Catalogue goes beyond our expertise and should have more input from dnsop and operators.
• Eric Vyncke with AD hat: cannot squeeze this I-D into the ADD charter though the content is interesting and useful. Go to DNSOP, or include it in the larger info deliverable in charter. Discussion can continue, but not adoption with the current abstract and content.

Other Discussion Topics

Thank you to the scribes, Martin Thomson and Watson Ladd.

Planning & Wrap up

• 5 min - Wrap up + Future Planning

As Time Permits