WG: DNS PRIVate Exchange (dprive) Meeting: IETF 95, Buenos Aires Location: Atlantico C Date: 2016-06-06 (Wednesday 6 April 2016) Time: 10:00-12:00 ART (13:00-15:00 UTC) Chairs: Tim Wicinski Warren Kumari Minutes: Shane Kerr # Document status # https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/ Dan Wing Ready for working group last call Sara Dickinson: Have made comments that handling of sessions still slightly unspecified. More closely aligned to DNS over TLS than specified. More alignment would help. A whole number of things that need to be taken into account. Dan Wing: Achieve realignment... how? Sara Dickinson: Similarity and differences would make it easier for implementors. Sara Dickinson: Wondering what implementation status is. Questions about how it will work in practice. --- Paul Hoffman: Which way to do comparison? We ended up having to add a lot of TCP-ish stuff which you don't have. If you follow the same order as in UDP stuff it would be a lot clearer. Paul Hoffman: I disagree that we need to have implementations. In the IETF we don't do that. --- Ted Hardie: Note RTC web data channel (SCTP over DTLS), which is a "Foo over TLS". You may want to contact them. --- Sara Dickinson: Wondering if we can make it an experimental? Is that an option. Dan Wing: It's a working group document. Whatever you want to do. Warren Kumari: One issue is getting review. Only small number of people providing comments. Warren Kumari: After rearranging we can start a working group last call. # https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ Sara Dickinson Ted Hardie: Like this presentation. However, maybe opportunistic is covering too much ground, and we should split it into the case of encrypted versus fallback to clear text. Might be clearer to people looking at these labels as to what these look like. Sara Dickinson: I agree. There are slides later which talk about that. ---- Christian Huitema: Confused about the useage. It's a VPN to your resolver. That resolver in my mind is authenticated by the client. "This is the resolver I trust." That trust means it won't lie to me, share my data, do nasty stuff with the DNS, etc. I want my DNS packet to go there. Sara Dickinson: That's "strict". Christian Huitema: When I read your draft I see a different model. My fallback case may be that I don't send all of my traffic to a server. The interaction between the dynamic model and the other model is not clear in the draft. Sara Dickinson: The distinction is "choose whether to be strict or not", and then how you choose to do that is a secondary consideration. Christian Huitema: But look at the information leak. The reason we do dprive is because I don't want the guys in the coffee shop to know which DNS names I am using. If I use opportunistic servers then it is almost the same as disclosing my names. Sara Dickinson: In that situation you will either use strict or not. You're not going to jump around. Christian Huitema: My suggestion is: there should be a usage model for this document. ---- Ted Lemon: Confusion about opportunistic means that it is broken. Sara Dickinson: We didn't have "no privacy" to begin with, we added it for ---- Stuart Cheshire: We're using DNS server to mean two different things, because of historical accident. I was understanding this to mean "this is my first hop to my recursive". If I configure 8.8.8.8 then I have privacy to that. If other people are reading that differently, then there is miscommunication. Sara Dickinson: We explicitly say that. Stuart Cheshire: I agree, but if there is confusion... ---- Christian Huitema: Lookups are typically done gethostbyname() or somewhere in the bowels. I don't get how the USER will make the decision? Sara Dickinson: It's not in the spec. That's one of the reason we worked on getdns to expose the work to the user. But I agree. Christian Huitema: Am I supposed to pop up a warning to the user? "Hey grandma, we have a decision where we can't reach a trusted resolver." Is that what we want to do? ---- Stephane Bortyzmeyer: I'm not sure I understand questions about usage models. But if I understood, then I disagree. There are MANY MANY usage models. Too many to list. So I like the approach of this draft, because it could be realistic. We need something in between, even if it not easy to describe it. Stephane Bortyzmeyer: Now for UI. There are a few UI points in the draft. It's typically not our business. There are many ways to interact with the user, and we don't know all of them. It's generally not a good idea to turn us in to user interface experts. Up to software authors to give a choice. ---- Paul Hoffman: Authentication by domain name only in scope. I think that's a mistake since DHCP gives an address. Sara Dickinson: But you need a trusted and secure DHCP. Which you don't have... Paul Hoffman: Saying this is only or coffee shops is too limited. Or if you have a DHCP that says 8.8.8.8 and it has a certificate then you should be able to use it. Sara Dickinson: I could see this happening in the future, but I don't want it to block this document. Paul Hoffman: No, don't block just say it... ---- Christian Huitema: Problem not discussed: what happens in enterprise network where you *really* want to use the enterprise server. Versus when you are in a coffee shop where you want to use your pre-configured resolver. Sara Dickinson: Do you see that as something we should specify? Christian Huitema: Describe the problem. It's a question of configuration. Warren Kumari: Would you be willing to provide a document that discusses this? Christian Huitema: Yes. --- Stephane Bortyzmeyer: Is it possible in a typical CA to get a cert for an IP address? Describe the problem. It's a question of configuration. Phillip Hallam-Baker: Yes you could, but no you can't. I think that every service should be accessible by a domain name, particularly in IPv6. Dan Khan Gillmor (dkg): I want to agree with Phil there. People want to be authenticating to a server where they know what it is. ---- [refused to identify] (not dkg): It seems to me that there are 2 scenarios: 1. We have a human-entered name. Mapped somehow to key material. 2. Machine-entered doo-dad, which came from somewhere else. Might be nice to have lookup for the key material... but that won't work out well and you should either deliver a domain name or also include the key material. ---- Phillip Hallam-Baker: Recently in Turkey people were posting "8.8.8.8" everywhere. The problem there is that it was very fragile. What we saw is during the middle of the day the traffic quadruplied at our public DNS when 8.8.8.8 was blocked. You only need to do this binding once, you don't need to acquire the DNS address every time. # Google DNS over HTTPS disclaimer Warren Kumari: Google DNS over HTTPS not designed to compare with DNS over TLS. # TLS 1.3 update Dan Khan Gillmor (dkg) 0RT (0 round trip) data has a number of subtle differences. Differences: 1. Can't do client authentication. 2. Forward secrecy guarantees are different and less. 3. No replay detection. 4. Client privacy (sessions can be tracked across the network). Shane Kerr: No client authentication? Dan Khan Gillmor (dkg): Only for 0RT, which is session resumption. ---- Ted Hardie: You can handle this with client limits (like time). Dan Khan Gillmor (dkg): Yes, as long as the server can store that state. In anycast situation we don't have any guarantees that this will happen. Dan Khan Gillmor (dkg): There are mitigation strategies. Ted Hardie: There are strategies to limit this. In anycast your 0RT resumption may only be valid for the server you got to first. ---- Paul Hoffman: Correction. Only the first query is replayable. Dan Khan Gillmor (dkg): All queries in the 0RTT. Paul Hoffman: If you have 1 query, then that is 1 query. Dan Khan Gillmor (dkg): Until you have gotten the 2nd part of TLS back, you can replay. ---- Stephen Farrell Good analysis. Hope other FOO over TLS do the same thing. Stephen Farrell Reasonable to do recursive to authority? Dan Khan Gillmor (dkg): Yes. Also, client has the option to construct a profile that avoids showing the session ID, but not for resumption. Important to insure that DNS over TLS clients only resume a given session. ---- Christian Huitema: Should have a discussion about TLS privacy issues discussion. Not DNS specific. Dan Khan Gillmor (dkg): I agree. But as a DNS community we can say "you must use this kind of profile as a DNS client". ---- Ted Hardie: If I get session resumption ticket, if I use that resumption ticket on that network for the first time then it is safe because I can link it to the recursor but not to the client. So never *re-use* on a new network. Dan Khan Gillmor (dkg): I think we need to be sure that queries coming from the same IP address may not be from the same client. Ted Hardie: That's worth writing down. ---- [refused to identify] (not dkg): In (TLS) 1.2 if you wish to have new sessions you must re-issue new connections. Dan Khan Gillmor (dkg): Yes. ---- Allison Mankin: Should we have have text in the DNS over TLS documents? Terry Manderson (AD): I don't want to see this text in those documents. I'd like to see it in a separate document for dprive. ---- Phillip Hallam-Baker: There are ways you can do it if you allow server state... Dan Khan Gillmor (dkg): Sounds like we are brainstorming TLS resumption patterns, and maybe we should do this somewhere else....