DNS over HTTPS Working Group - IETF 104, Prague
11:20 - 12:20 AM, 26 March 2019
Grand Ballroom

Note Well
  https://www.ietf.org/about/note-well/
  
Charter: https://datatracker.ietf.org/group/doh/about/

Working Group Chairs:

Session Chairs:
Agenda



    
Minutes
11:20 Meeting Begins

---------------------------------------------------------------------------------------------

11:22 Paul Hoffman discusses issues brought up by draft-ietf-doh-resolver-associated-doh

https://datatracker.ietf.org/meeting/104/materials/slides-104-doh-draft-ietf-doh-resolver-associated-doh-00

Ben Kaduk: This topic is off-topic based on IETF mailing list charter (rfc3005/bcp35). 
(Regarding discussion occuring on many different lists.)

Martin Thompson: Suggestions were made on how to achieve the goals better.

Eliot Lear: "Ickiness" is too abstract of a word. Hard to understand the conversation.

Presentation ends

Brian Dickson: One issue with the use of possibly DoH servers where there are existing chains of forwarders. Need to be able to disambiguate entities in the forward chain, who identify themselves separate from this.
Paul Hoffman: Send to list.

Eric Rescoria (ekr): Now we can talk about authentication 

Paul Hoffman: Well-known URI has authentication, others cannot.

Eric Rescoria (ekr): High-probability 10.0.0.1. Even if not true, ordinary behavior is going to be try and assume no DoH if you can't connect, and fallback to unencrypted DNS. Attacker can cause fallback. Not enthused about this.

Paul Hoffman: Are you against it?

Eric Rescoria (ekr): Don't see any value. JavaScript apps probably know which server they want to use.

Paul Hoffman: often people would know what they want populated there anyways eg: browser vendor

Ralf Weber: Don't want to run HTTP servers on my recursive resolvers. Always get special name and resolver can send you to HTTP server.
    
Martin Thompson: Objections are more fundamental. Agree not wanting HTTP server on resolver. But why are we talking to an HTTP server about a DNS server in the first place? Why can't we talk to the DNS server? In other protocols we have ways to talk to the other endpoint; in DNS we have no way to talk to the resolver itself. In HTTP we can put in header fields, and specify the connection is doing various things, and so on. If we could ask the resolver, "what is your configuration for DoH?" we would be in a better place.
    
Jon Reed: You have presented a set, is there room for discussion to consider it in order?
Paul Hoffman: It's an open question.

Jon Reed: Can we make a recommendation that saying "there is no DoH" should be explicit?
Paul Hoffman: Not normally what we do...
Jon Reed: Maybe we can also put IP addresses in there since TLS can often fail unintentionally.
    
Patrick McManus: Concern that people say "I am okay using local resolver since I trust my local network". They don't trust their network, they trust their network provider. 

Paul Hoffman: Short-term terminology changes were meant to touch on the issues you raise. Go ahead and talk on DNSOP.

Patrick McManus: DoH server chosen through this mechanism is not authenticated more than your network is.

Paul Hoffman: Send text.

Ted Hardie: In the draft, instructions to IANA: "Names MUST NOT be delegated". 

Paul Hoffman: Send text.

Ted Hardie: These are specific to DoH, but could imagine making these TLS-protected DNS servers return DoT and DoH. Would you be open to expanding scope?

Paul Hoffman: I would be, but this is the DoH working group.

Ted Hardie: Affects instructions to IANA.

Warren Kumari: Sympathetic to doing from JavaScript, but ...?
    
Erik Nygren: Do we need all 3 mechanisms? Using DNS as a resolver is attractive compared to other mechanisms. Special-use domain name solves a lot of problems. Of these, the only one that you could use in JavaScript (bootstrapping needs to know what resolver is).

Paul Hoffman: But JavaScript cannot use this. Valid question is "simplify down to one?".

Erik Nygren: Even if not possible today, could we expect that in the future it would be?
    
Ben Schwartz: At least 2 different options in draft. 1: New problem - think of all possible solutions & list ones that are likely to work. But we should pick a single solution; go to implementers and see which solution they prefer. No input from people building local network clients. Not much input from browser vendors. 2: No web API for reading an IP address. Even if you can resolve a name you cannot find which IP address it resolves to.

Paul Hoffman: Did not know that there was no way to resolve IP address. If that's wrong then the whole thing is wrong but nobody has pointed it out yet.

Ben Schwartz: My understanding is that there is no such API. Otherwise we need a W3C liaison action to create such an API.

Jared Mauch: Current trend to encapsulate protocols inside of other protocols. Concerned about how we continue to do that, and we should discuss solution spaces. Recursion involved in that is relatively hard. Vendors will say "now you need to implement all of these different stacks". Concerned about this level of complexity. Some benefit to users, but broader than  browsers. Interactions are complex. If we need to ask vendors to implement new things, standards like this concern me.

Petr Špaček: For us as resolver vendors, no point in us implementing DoH if nobody can find it. This is way more important than it seems, otherwise we will be stuck with Google as an endpoint. DHCP workgroup has been trying to solve security in DHCP for at least 7 years. It's just a hard problem. We shouldn't wait for solving that problem in order to have a DoH option for the client. 

---------------------------------------------------------------------------------------------

12:00 Jason Livingood and Jim Reid present Centralized DNS over HTTPS (DoH) Implementation Issues and Risks ~and~ DNS over HTTPS (DoH) Considerations for Operator Networks

Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-doh-doh-implementation-risks-and-operations-considerations-01

Tale Lawrence: Unstated option of "not appropriate for the IETF".

Pete Resnick: talk about where stuff should go and what are important things to go.

Tale Lawrence: Was going to be a model of a "pop-up working group".

Stéphane Bortzmeyer: No, not in charter for DoH working group. Not a DNS-specific topic. Bigger problem for the Internet: dominance of big players like Google. Is work on a draft about consolidation. Maybe DNSOP if DNS-specific, maybe IAB work if broader; not in favor of a new working grouop.

Vittorio Bertola: All discussion should be in one place. Was related discussion at ICANN(?).

Watson Ladd: Concerned that drafts are looking at DoH and operational issues at DoH, ignoring a long history of misbehavior by ISPs in DNS.

Stephen Farrell: Analysis is not sufficiently baked. Has to be redone before I would have a clue to how the IETF should go forward. Asking for the impossible: do it objectively!
    
Suzanne Woolf: As DNSOP chair. This does not feel like DNSOP work to me. It is operational but more than DNS people could come to analysis and correct answers. Feels more like recharter or BoF + WG or some other way to get this done.

Suzanne Woolf: As IAB member (but not speaking for the IAB). Discussion has gotten more challenging because it is difficult to separate layer 9+ issues from technical ones.

Ben Schwartz: Not speaking as a chair. I would appreciate a clearer taxonomy of the issues. Browser-related components should be transfered to W3C.
    
Warren Kumari: Every time we say DoH, we could say DoT. Want a new mailing list: ADD (applications doing DNS).
    
Gurshabad Grover: Some issues are superficial. Are advantages.

Kirsty P.: this is important work and I want to see it happen and I don't care where.
    
Elliot Lear: Work should continue in the IETF. Agree with Ben Schwartz that taxonomy needs work. 

Patrick McManus: Very similar to prior pervasive encryption work.
    
Brian Dickson: DNS stateful operations has applicability to DoT to signal privacy from one server to another. Don't know where work with that would be.
    
Ralf Weber: Some of the issues are DoH & DoT, in the same boat. Need to come up with operational ways to deal with these. One issue is provisioning and needs to be solved for both DoH and DoT.
    
Leslie Daigle: Push back on idea that this will get punted to W3C. Fundamentally this is a question about how do DoH and DoT break host assumptions about DNS.
        
Wendy Seltzer: From W3C. Third time W3C mentioned I was summoned. I don't see a reason for W3C to say it should happen in that group. And I haven't heard this conversation in W3C groups. I can poke at groups if you would like for them to be engaged.

Pete Resnick: ADs & chairs will discuss.
    
---------------------------------------------------------------------------------------------

Thanks for all the help with the minutes everyone! - Shane