Application Behavior Considering DNS (ABCD)

WG-Forming BoF

Meeting: IETF 106
Date: 2019 November 19
Session: Tuesday Afternoon session I
Time: 13:30-15:00 GMT+08
Room: Padang, 4th Floor
Area Director: Barry Leiba
Chairs: Dave Lawrence, Ben Schwartz
Note takers: Tim Wicinski, Joseph Lorenzo Hall
Jabber scribe: Suzanne Woolf

Agenda

00-05 Note Well and Agenda Bashing

05-10 Introduction and background refresher (Chairs)

• (timeline of encrypted transport for DNS)
• Client imps have progressed.
  • MSFT Windows just yesterday
• Numerous server deployments and trials
• Many drafts related to client configuration introduced this year
• We are not just talking about DoH, but the evolving DNS landscape
• Drafts related to systemic considerations
• Number of controversies about this topic
  • Please be respectful and focused!
• Tooday's conversation:
  • Working group-forming BoF

10-20 Report on canary domain experience (Andy Grover, Mozilla)

• slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-abcd-mozilla-canary-domain
• Explanation of rolling out DoH, specifically the use of canary domains
• Working to mitigate side-effects
• Can bypass parental controls present on the network
• We need to detect this and disable DoH
• (other heuristics help with other side effects)
• We don't want to use reachability of explicit domains to do detection, we need something a bit less sexy (logs shouldn't implicate the user)
• technique: use platform DNS to resolve a test domain, deduce a DNS policy is present, disable DoH
• Mozilla's: `use-application-dns.net`
• if NXDOMAIN, or success with no A or AAAA record, canary domain positive result, disable DoH
• RPZ can be used to configure response in bind9
• Pi-Hole supports this, have been running studies on Canary trigger rate
• also watching for abuse (blocking canary above end-customer level)
• pre-emptive "why didn't you do x?"
  • wait for standardization? Needed a quick solution that didn't depend on other people's sw supporting
  • Flip the logic so DNS lookup success means policy is present? 
• Are interested in less-unilateral approaches... fewer canary domains would make easier for apps.
  • could use a reserved domain.

• Q&A:
• Ted: you can reserve domains easily now under .arpa
• Brian x:  would you be willing to publish all your heuristics?
  • The extension is public, so yes.
• EKR: we publish in several ways. Blog post. Source code of web extension.
  • not useful for standardization as they're full of OS APIs, user configuration of FF, etc.
• Roy Arends: canary domain is two-level doman, in bind need to configure RPZ (didn't catch this)
  • make the domain have another label in front of it
• Bernie Hoenisen: it's an awful argument to do parental control in the DNS
• David Schinazi: there is precedent... IETF has standardized something.arpa (ipv4only.arpa) . Operators override this to share that there is something in the network.
• ? (Android): hard to distinguish parental control from other types of control/censorship

20-35 Overview of the Adaptive DOH proposal (Tommy Pauly, Apple)

• slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-abcd-adaptive-dns-privacy
• Some of the design decisions we are working on may be useful to others
• (illustrations that show with DoH skipping local resolver)
• How can clients discover encrypted DNS resolvers?
  • hard-coded or configured
  • bootstrapping off of HTTP connection (~alt-svc)
  • Using records in the DNS, using DNSSEC-signed records that a client can use to indicate DoH URIs
  • Why are we talking about DoH and not DoT?
    • DoH is often described as hiding traffic... but there are a lot of other benefits: multiplexing, direct transition to QUIC, ability to proxy
• How can networks advertise local policy?
  • Canary domains
  • DHCP/RA options
  • Provisioning domain options: indicate filtering rules, walled garden/captive status, define domains for local resolution (CDNs, split horizon)
• How can client choose the right resolvers to use?
  • (illustration of client resolution algo)
  • precedence: VPN resolver, Designated local resolver, designated DoH server, oblivious DoH, Direct resolver
  • How do we bootstrap this kind of scheme?
  • if you trust the local network, designated DoH can be found with local queries

• Q&A:
• EKR: we have a problem with ESNI that a single domain could be served by two different CDNs. What is the impact of designating one (?)
  • we use the same record for designation that is used for ESNI.
  • owner of the domain doing the load balancing can indicate which
  • EKR: status quo may be pinned and never can change, that would be no bueno
• Warren Kumari: for designate DoH, can I say that google.com can resolve youtube? Yes. what about apple.com?
  • these should be DNSSEC-signed... there needs to be a proof of authority (Perhaps look at RDBD draft)
• Jari A.: concerned with centralization.
  • What do you do when multiple parties that can resolve a particular name?
  • A: similar to EKR's first point. Many of these servers will be able to resolve the whole internet. we'll need to discuss
• Ralf Weber (Akamai): How can you make sure that ISP doesn't get (?)
  • depends on initial resolution/bootstrapping. We should be able to trace down where this is happening.
• Ray Bellis: Names that are not DNS names are not in your illustration of precedence.
• Brian Dickson: from a caching perspective, when a client flips from one resolver to another, might want to have a forwarding mechanism to optimize caching. (?)
  • A: authority servers should have very high hit rates.

35-45 Charter presentation (Chairs)

• proposed charter text: https://datatracker.ietf.org/meeting/106/materials/slides-106-abcd-proposed-charter-text-revised
• We are looking for concrete work items that we could adopt in their own WG.
  • Final decision is up to the IESG. We are able to discuss and modify the charter text they chomp on.
• Notable changes to the draft charter.
  • lots and lots of discussion on the draft charter
  • produced an updated charter proposal.
  • some highlights:
    • expanded the detailing of the initial areas of focus
    • want essential and less controversial items of work
    • latest draft changes the phrasing and adds a condition
    • if ther are substantial disagreements those are resolved outside of the WG so as to not take up time

45-90 Charter discussion

• Aaron Falk: confused by "full consensus". Is this a different standard than our typical one?
  • Ben S: blame me. If someone comes up to the mic in a WG and says "no, I'm not going to do this" that has to happen outside the WG
• Jen Linkova: I'm a bit scared about potential implications for networks I run. I would love to see DNS64 mentioned.
• David Schinazi: DNS enthusiast. That's a lot of stuff on the potential areas of work. Lots of these are in the charter of DNSOP
  • A: the audience is much broader than the typical audience for DNSOP. There is a lot going on there, and people that want to do this don't want to do all of DNSOP. we want to increase participation.
  • DS: saying that another WG's agenda is too full doesn't sound like a good reason to peel off another. Needs too be narrowed a lot
• Jari Arkko: we shouldn't focus too much on where the work ends up. let's focus on which things are needed.
  • I take exception with one of these items excluded from scope: privacy and surveillance items. Seems like a major miss if we don't work on those things... esp. according to our BCPs.
  • BS: this is not an "out-of-scope" list, but a DANGER DANGER DANGER list.

DANGER DANGER DANGER

• Patrick McManus: Are Chairs Proponent of the WG?
  • DaveL: yes [Dave here: well, not exactly; I answered in the vernacular, not in the IETF term of art sense]
  • Ben: neutral
  • (Damn, lost network!)
  • Patrick: this is not a good charter... no deliverables, full consensus, no idea of what success looks like. This is not ready.
• EKR: Have not come very far from the last BOF. We publish technical specs... what specs can we publish that would be output. There are way to many ideas of things to work on, EKR likes number 2 (discovery of resolvers).
• Brian Dickson: (something something0
• mnot:  Do not think we should go forward based on this charter, you've built conflict into the charter. Need something smaller and distinct. There are some interesting and useful things in this space. Strongly against this charter.
• Brian Trammell: likes the charter on the left (small) than the one on the right. How do I figure out what my environment looks like for resolution? Let's pick one and then say "close or recharter", should do in a more serial way. Have opinions about "notable changes (2)" slide... we are going to need discilplined chairs. This WG needs to exist, not with this charter. Should spin somehting up before Vancouver.
• Jim Reid: (JLH cannot understand what he's saying, sorry)
• Brian Dickson: from RHS, the first bullet "end-user privacy and pervasive surveillance", should be part of all drafts just like Security considerations. (?) is a huge red flag. Would prefer to see something a bit more neutral and something that requries Robert's Rules. As a process we should be open to discussing those things without being uncooperative. For WG content would make sense to have more structure in the deliverables dependencies (?).
• Nalini Elkins: would like to support debugging and analysis and measurement. preso in (?) where multiple queries were sent when only one would suffice. we need to understand this traffic and how it works.
• Jabber scribe (Chris Lemmons): "Responding to Patrick. While it's true that the charter could use improved specificity in deliverables, it's inaccurate to say that there are no deliverables present. There are several specific topics in the charter like discovery of resolvers, DNS Push, and such that could certainly be turned into the basis for the specific working group items fairly directly."
• Lemmons: "I'm significantly in favour of working group formation. It's unclear to me how to put "discussion" in scope but not resolution of disagreement. Resolution of disagreement is a major part of what working groups do. Every working group has to narrow scope of discussion (sometimes taking the discussion offline to breakout groups) when topics get hot in order to get things done. I think monitoring that conversation is just part of the (admittedly difficult) work of the chairs. I don't know that the charter should put those topics out of scope, particularly since we'd benefit significantly if we came to consensus on some of those topics."
• Suzanne Woolf as DNSOP co-chair: good to have two WGs, and they can work collabortively. DNSOP chairs would be able to consult, there's not necessarily the expertise in DNSOP for this work.
• Alissa Cooper: Both of these charters were designed by committee. Piling on with Suz, there is precednt in the ART area to peel off work for overloaded WGs. Given the nature of this, this is the worst topic to introduce a new type of consensus, let's use what we know that works. In this discussion, people are so dug in that people know what folks are going to say... need to find a way to (?)
• Andrew Campling: there is a need for a WG. first for bullets on RHS are good material.
• PHB: supportive of alternative ways of DNS resolution. really worried about "full consensus". This allows taking power from people and giving it to others. Need to think in addition to who queries are protected from, where the queries are now going.
• Ray Bellis: ART is not the place for this. This is a better fit for INT. 
• Ralf Weber: we should form the WG but we haven't had a structured discussion that will happen when the WG is formed. let's get it done.
• ?: ?
• Chris Box: support WG here. I would like the WG to have a specific narrow focus. LHS is too short, RHS is too long. Wants to see resolver discovery.
• Glenn Dean: supports WG formation. sometime we don't have consensus and that can be valuable to know. policy is a place we should stay away of
• Vittorio Bertola: supports it. there is actual technical work that needs to be done. E.g., don't want to support 10 different canary domains. The discussion here is much broader than the IETF.
• Rich Salz: strongly opposed with the process changes in the charter. (no strong opinion on substance) Vetos can be problematic. Don't want to do something that goes against what we know that works, our history.
• Martin Thompson: echoing Patrick, hearing a bunch of people saying they want to do x in a WG, but not a lot of specificity about what x is. We need to have more concrete and focused discussions about particular proposals.
• EKR: we are six minutes from the end of the session, no hums. A Charter that has the first three things (the LHS) and lets do that. Let's hum!
• Kirsty P (NCSC): detection and supression of malware should not be controversial. We see a lot of benefit from various malware defenses, and DNS is part of that. For forming a working group
• Richard Barnes: there is a WG hidden in this that I can support... not with any of the charters heretofore presented. We need to have a tight focus with clear deliverables. 
• Daniel Migault: consensus should not provide a right to veto.
• Eliot Lear: a WG is not the only vehicle that we have. They can be discussed in an IAB workshop, IAB program, IRTF. Would ask the IETF leadership to look at the RHS of where and what would be the right forums.

• Barry: after listening to the mic discussion we don't have much we can hum on. Hear people wanting to work on something and we can't agree what we want to work on and that the RHS is too long.
• Alissa: we have a list on what a successful BoF is and this is not it. And now we have to do it on the list.
• ? Verizon: Applications are doing DNS (AADD), that's a fact. RHS is a good list.
• ? (Orange): support the original version.
• Brian Dickson: support 2, 3, 5, 7 on the RHS

https://datatracker.ietf.org/meeting/106/materials/slides-106-abcd-proposed-charter-text-revised