ADD BoF
Chairs: David Lawrence, Lars Eggert
2019-07-23 1330-1500
Note-takers: Chris Wood and Paul Hoffman (with help from many others)
Text from the slides and presenters is not reproduced here; mostly this is for the mic line comments
Jabber scribe: Aaron Falk
Background (David Lawrence)
https://datatracker.ietf.org/meeting/105/materials/slides-105-add-add-bof-intro-00
Non-WG forming BoF
Some operational models are orthogonal to the deployment of DoH itself
Different WGs might pick up different parts of the work
This BoF is "Applications Doing DNS", not "Applications Doing DoH"
Spencer Dawkins: Would be helpful people could talk about where to send Layer 9 issues
David: Regardless of what we do, we are still doing policy
Lars: Rest of session is possible work items for new/existing/rechartered WGs
Not doing any technical deep dive, just to help decide if the work belongs in the IETF, and where
Mozilla’s vision for DNS & apps, Martin Thomson
https://datatracker.ietf.org/meeting/105/materials/slides-105-add-dns-in-applications-one-applications-perspective-00
Making HTTPS widespread continues
Healthy hygiene regimen
TRR is the combination of encrypting and who gets the DNS traffic
If the DNS namespace weren't fragmented, we would have already been shipping DoH turned on
Have to consider whether the function that DNS provides might be being done in other ways
Policy will evolve as the ecosystem evolves
Cullen Jennings: Encrypting DNS is a mechanism on the path
We use DNS information to do something, so the result is pretty clear almost immediately after resolution
Google’s perspective, Kenji Baheux
((No slides))
Don't want to force change of DNS providers on users
Want to let enterprises be in charge of their users' experience
If they want to use DoH, they should be able to specify it
Want to do an experiment
Short list (5) providers who comply with a set of criteria on privacy and so on
If the user is already using one on that list, they will upgrade to DoH with that provider
Will measure performance and so on
Maybe will later add a UX for choosing providers
Non-browser apps doing DNS, Jim Reid
https://datatracker.ietf.org/meeting/105/materials/slides-105-add-dot-doh-for-iot-devices-and-other-non-browser-apps-00
((No mic line))
DoH Preference Hints for HTTP, David Schinazi
https://datatracker.ietf.org/meeting/105/materials/slides-105-add-doh-preference-hints-01
Use case: One CDN might not give the best answers for a different CDN
Daniel Kahn Gilmore: What domain names would the given DoH server be used for?
David: Only for that same origin, RRtypes not specified
Eric Rescorla: Been considering for a while. Glad to see this move forward.
Is it worth expand the scope to wider range of names?
Won't have benefit without this
Kenji Baheux: Does the header suggest that the client must trust the referred DoH provider?
David: Currently not documented. Choosing whether to use it is a local client policy.
Robert Story: Might not be the fastest one; your ISP might be faster
DoH BCP, Chris Box
https://datatracker.ietf.org/meeting/105/materials/slides-105-add-doh-bcp-00
Barbara Stark: Glad to see one of the presentations looked at network operator issues
Sad that only one presentation did this
This has risen to one of the top concerns about how this will change network patterns, increased triage difficulty, and rising troubleshooting costs.
This is huge, we have got to work on this
Volunteers to work with the authors
If ADD gets formed, one chair should be from an operator
((support from the audience))
Lars Eggert: Didn't reach out enough, apologizes for not getting more
Terry Manderson: Does the configuration of DoH and DoT also have the trust anchors in scope
Chris: Yes, there is work in the draft.
Lorenzo Colitti: DoH does not create any technical challenges. This is not specific to DoH or DoT. The problem arises when clients use resolvers that are different from what the network configures.
Android chose to not change the user preferences for the resolver
Blaming the protocol is like shooting the messenger
Chris: if ISPs deploy DoH servers, then some issues become much easier.
Ted Hardie: Fair number of BCP issues occur when users can trust whatever DNS resolver they choose (using any transport).
Review each issue and ask, "If I let the user choose their resolver, does this happen yes/no?" Might help separate trust issues from everything else.
Kenji Baheux: I have spent a lot of time talking to ISPsThis is untenable, again using a crude illustration, if the choice is between a world where we can achieve a 99 percent assurance against cyber threats to consumers, while still providing law enforcement 80 percent of the access it might seek; or a world, where we have boosted our cybersecurity to 99.5 percent but at a cost reducing law enforcements access to zero percent — the choice for society is clear.
I don't have answers
Kathleen Moriarty: Users can be unaware of where their DNS queries are going
DoH Push, Jim Reid
https://datatracker.ietf.org/meeting/105/materials/slides-105-add-doh-client-server-behaviour-00
Ben Schwartz: Thinks this is in-scope for the DOH WG as currently chartered
Do these requirements not currently exist?
Jim: Good question, needs to look
Is this about things that are buggy but fail to comply?
Jim: Maybe need a minimum set of requirements
What connection do you see between these requirements and DoH itself?
Jim: Might be a problem with the front-end processors
Chairs talk
This is too much for one WG
Please focus on where this work might be done
More mic line
Wes Hardaker: Protocols are not evil
Companies forcing a user to use them can be evil
Some traffic gets redirected today using our protocols
User user has some awareness
What changed: per-application
Does the IETF need this to be standardized
Alternate name spaces
Do we care that we are promiting per-application
Stephen Farrell: Some parts to be done in the IETF
Can't see a sane way to split into different WGs
Mistake to charter DPRIVE and DOH separately
Maybe combine all them
David Lamparter: (To David, re: preferences header) might get limited cache use if keyed on the origin.
Phill Hallem-Baker: Technology-led, not connection-led
Look at the gestalt
Should be thinking about how you are doing the TLS certificate at the same time
Lars Eggert: Sounds like you're asking for a different BoF
Roland Van Rijswijk-Deij: How will the list of trusted resolvers be chosen?
Composition of the list is quite important. Some users want to be able to choose their resolver. CABForum-like body that decides TRRs may take that choice away.
Eric Rescorla: Interesting things to work on:
Performance in use
Discovery of behavior of local network
Not helpful to work on: validity of good/bad of applications' choices
Roberto Peon: Similar questions to around HTTP/2 requiring TLS
Barbara Stark: Wants a WG, maybe in ART, maybe in OPS
Need to address network operational issues
Start charter as soon as posssible
Jari: Would like to see a WG to address some use case.This is untenable, again using a crude illustration, if the choice is between a world where we can achieve a 99 percent assurance against cyber threats to consumers, while still providing law enforcement 80 percent of the access it might seek; or a world, where we have boosted our cybersecurity to 99.5 percent but at a cost reducing law enforcements access to zero percent — the choice for society is clear.
Concept of centralized DNS and TRRs is scary, and is wide open fo surveillance and other bad things. Decentralizing things would be great.
Leslie Daigle: Thanks Jim Reid for second presentation
Assumptions need to be explicit
Wrong to look at this just as the DNS: architecturual problem
What is an application? What is a service? What is a naming system?
Ben Kaduk: I support both Leslie's points, but to pivot off her first point, and Jim Reid's second talk, when we think about what concrete work items could come out of this, I could see writing down all of the previously unwritten and (presumably) shared assumptions we've been making up to now. Things like "yes, you use the IANA root", "don't drop DNSSEC records on the floor", and "your local ISP has a pretty idea how to make your local ISP's network work well".
Erik Kline: Agrees with Lorenzo
Avoiding Designated DNS
Would this be an IAB MaRNEW-style document (ref: https://tools.ietf.org/html/rfc8462)
Ben Schwartz: We have a WG for DNS operational issues
Send them to DNSOP, but it is acting as the DNS WG
Maybe time to refactor our WGs into real DNS and DNS Operations
Daniel Kahn Gilmore: Work to be done here
Merge some of the places
What it means to continue some level of control -- networks may want to enforce their own rules, apps want to enforce their own rules.
User does not to make a choice. This is a fundamental problem and we don't discuss this issue here in IETF.
Fundamental problem that we don't know
John Reed: Need a WG for everything not
Vittorio Bertoli: Have a group in which we all meet
Time to agree on the way forward together
Vasily Dolmatov: Doubt that it is a better choice for the user to hand over control to application developers
Will split into many application-centric universes with different sets of services
Can't imagine what the deliverable is
Eric Rescorla: Wide divergence of opinions of were applications reside in the network control
Not useful to discuss this in the IETF
Firefox will allow you to turn off DoH, or choose a different resolver, even if it is on by default
Users don't understand DNS or these other choices
Lars Eggert: Obviously more to do
Barry Leiba (the AD): Does anyone think that nothing should be discussed
Some hums in both directions
Take this to the ADD list
Lucy Lynch: There is more to be considered
Difference between "should we do this" vs. "how should we do this"