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)
    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
    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
    ((No mic line))

DoH Preference Hints for HTTP, David Schinazi
    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
    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
    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:
    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"