WG: DNS PRIVate Exchange (dprive) Meeting: IETF 94, Yokohama Location: Pacifico Yokohama Date: 2 Nov 2015 Time: 17:10-19:10 Chairs: Warren Kumari Tim Wicinski Minutes: Shane Kerr ---- Administrivia Warren / Tim 10 minutes Status report from WG chairs ---- DNS over DTLS draft-ietf-dprive-dnsodtls Dan Wing 20 minutes https://tools.ietf.org/html?draft=draft-ietf-dprive-dns-over-tls Fragmentation and reassembly in DTLS Shane Kerr: We have a separate draft for fragmentation. I think it makes sense to treat fragmentation as a separate issue outside of DTLS. I am not sure that fragmentation is a good idea, but I think it is worth exploring in the general case. Andrew Sullivan: It gives me hives. It's just not good. I get what you're trying to do, but there is a point where the complexity will tip you over the benefit you are trying to get. There are other pressures that are making us look at DNS over DTLS... at what point is it going to be the last straw. The complexity of this may be that. Andrew Sullivan: The complexity of RR changing while fragmenting may mean that the server should know that it is fragmenting, so that complexity can go away. I agree that if you are going to pursue it you should unify it. Paul Hoffman: I agree that we have to do it all or not do it. There has to be at least 4 areas and 12 working groups that have dealt with this over time. I tend to go towards "don't do it". I don't mean it is not a problem, but the SOLUTION is such a big problem... "don't do it". Paul Hoffman: I disagree with Andrew that the server should marshall the whole answer... that is the right solution if the server is going to do it. I believe that asking the server to do that is going to risk failure. Not doing it is not a problem. Warren Kumari: The fragmentation seems really scary. There's fragmentation in IP and we found scary security issues. There's fragmentation in IPv6 and we found scary issues. Dan Wing: On security concerns... this is above the DTLS layer. So any fragments will have passed the DTLS. Christian Huitema: There are already 3 or 4 ways of doing this. I would rather punt the problem until we have DTLS last call and not doing it. Ted Hardie: The tl;dr version is: fallback to TCP. Introduce it more generally that anyone running over TLS can. Shane's proposal to move it out as the general solution seems good. Ted Hardie: I still think it is worth doing. Sending larger things over UDP and the record layer will still be useful. I think it will be valuable in other cases, so you can leverage those other values to get people interested in the work. Ted Hardie: I don't think it belongs in the "giant bucket". I think it is a constrainable problem. Ray Bellis: Whether I feel fragmentation is good or not, I think it should be independent of the DTLS. I also agree with Andrew Sullivan about maintaining the RRSET. John Dickinson: So many things wrong, I think we should pull it. Dan Wing: Okay, we will pull it. ---- DNS over TLS draft-ietf-dprive-dns-over-tls Allison 30 minutes https://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-01 Duane Wessels presents. Sara Dickinson presents. Duane Wessels asks audience for questions & feedback. Tim Wicinski: Does anyone have anything against putting profiles in another document? Wolfgang Beck: My main question: how many sessions can you run in parallel? 10000? This is the basic problem. We have 1 million per server, but... Duane Wessels: The document gives advice on optimizing performance in this area, and cites some research one of the co-authors is doing. For the most part the document does not make claims. Stephane Bortzymeyer: I agree with moving profiles to a future draft. I would also like that TLS and DTLS will be able to refer to the same document. I have a question whether the DTLS folks are happy with this solution. Sara Dickinson: We have had some discussions between us, and we agree that a combined, separate draft will work. Dan Wing: That is the best way to insure consistency. Andrew Sullivan: It strikes me that these are fairly fundamental changes to a document at end-of-last-call. I recognize that in the implementation it is not fundamental, but in terms of understanding the document, it feels a bit rushed. I wonder if we need more experience? Sara Dickinson: Perhaps we have misrepresented. There are only two changes, apart from the profiles. Andrew Sullivan: I get that. It feels to me that the document - not the software or the approach - we are moving things around that is changing things. Allison Mankin: This is a very extended last call. There are 2 weeks left of it. Andrew Sullivan: I am just asking. I am not trying to say "no". Paul Hoffman: We might shift stuff into this security document. That may change over time. I suspect that this will happen once people start reading about opportunistic. Every time this has come up in the IETF people very much cared about specific wording and specific scenarios. I would not be surprised if it too months, simply because of opportunistic encryption. I don't wish for that, but... Allison Mankin: I think proposed changes are on the order of 3 or 4 sentences. Christian Huitema: I like the change, I like the different scenarios. This implies that there has to be some sort of client authentication. It is probably goinig to be quite some draft. Sara Dickinson: There are some things we can explore, not just in the case of TLS certificates. We may be able to use DANE, or the whole chain. Christian Huitima: There is another issue there. If we look at serious deployment in a large-scale service, I am a bit concerned that we will have a merging of security for a large number of credentials. Daniel Kahn Gillmor: Your first question was about client authentication. I hear what you were saying about wanting a client authentication, but I don't think that is the idea of having a separate document. Christian Huitima: I understand that. But it costs a whole lot of money if I have 100 million customers. It costs me a couple of lines each, so I need to have some way to control that. Daniel Kahn Gillmor: I would be very interested in documenting more about client authentication, but the first document is about server authentication. I would be interested in exploring client authentication and privacy. Warren Kumari: Does anyone think that we should split into separate document? Warren Kumari: Does anyone think that we should NOT do this? Warren Kumari: whoo hoo! ---- Stateless DNS Encryption draft-krecicki-dnsenc Ray Bellis / Mukund Sivaraman 15 minutes Mukund Sivaraman presents. Mukund Sivaraman: How many have read this draft. Okay... that's not many. Roy Arens: What's the fallback mechanism? Plaintext? Ray Bellis: It's Mukund's first IETF, and it's not his work, so be kind. :) Roy Arens: I think you did very well, thank you for your presentation. Paul Wouters: If I insist on crypto then I can. I like the idea. I have been a little reluctant to add baggage. But again, I am wondering why not just set up IPSEC and do it that way. I'm not sure adding more crypto solutions is a good idea. Paul Wouters: We've also been trying to convey trust on the local system for the AD bit. It turns out there are just way to many stupid programs rewriting and updating /etc/resolv.conf. Perhaps the document should just say "configure locally". Paul Hoffman: I don't really like your draft for a number of reasons, which I might like later, but I suspect that I won't. This opens up a trivial DoS on servers. It is much easier for a client to create a bogus message that the server has to spend a lot of effort on to decrypt. If you add more state you can probably avoid DoS, but that will open up another, and another, and in the end you have DTLS. Paul Hoffman: The nice thing about TLS and DTLS is that when you are under attack you can reject connections. This is why other working groups have chosen not to do truly stateless. You will end up with where we are already at. I think it will be semantically equivalent to DTLS. I don't think we need a second thing. Paul Hoffman: Also, this working group is supposed to focus on stub-to-resolver. This draft requires entering in resolver into the reverse tree. This is not possible for everyone operationally. You may want to move your server a little - this is easy locally with DHCP. I think this has some nice ideas but until they are worked out you are better with DTLS. Witold Krecicki : Using the reverse tree is only one of two options. Sara Dickinson: The discussion about overhead in terms of 10's of bytes, this will be offset by whether you choose to pad to offset query analysis. Marc Mosko: I don't believe that returning a key under a key that has been compromised will give you forward security. Putting a key in the DNS record means you have a man in the middle attack. Mukund Sivaraman: It's DNSSEC protected. Andrew Sullivan: I want to thank you and your colleague for presenting your work. Mukund Sivaraman: It's only my colleague. Andrew Sullivan: Thank you anyway. Andrew Sullivan: The worry that I have is that this is quite a different direction from other stuff that we have been working on. It's really underspecified. At least 3 parts of it are excellent solutions for a different Internet other than the one we have. The problem of the reverse tree is an issue. To get this to work really well we need to get our parents work with us. This seems like a really big problem. Even though there are promising ideas here, this may be the wrong solution. ---- The Eval Document Allison Mankin 10 minutes Warren Kumari: How many people have read this? Almost no hands. Warren Kumari: The working group asked for this and the authors worked really hard on this, so it would be nice if people read it. Allison Mankin presents. Allison Mankin: Will you adopt this? We can make it a bit shorter. Do you want to keep references to out-of-scope work or not? Warren Kumari: The working group asked for this. 80% of the room at the last meeting seemed to think we should move forward. Who is willing to commit to review this. Paul Hoffman Sara Dickinson Andrew Sullivan Ted Hardie Benno Overeinder Stephane Bortzmeyer John Dickinson Dan Wing Wendy Seltzer Warren Kumari: Who thinks we should adopt this document. Hum now. Andrew Sullivan: I cannot believe we have a working group where we had 4 or 5 last time and 1 or 3 who claimed to have read it since the last time. I think it's nuts to adopt it. Put it on the charter! Warren Kumari: We can skip the adoption. Andrew Sullivan: I would be happy if in 2 weeks we had 5 people who wrote to the list saying they read it. ---- DPRIVE TLS/DTLS Profile and Message Flows draft-wing-dprive-profile-and-msg-flows Dan Wing 15 minutes Dan Wing presents. Allison Mankin: Has TLS heartbeat been analyzed for risk? Dan Wing: I don't know the answer, but we need a way to keep NAT/firewall alive. Christian Huitima: Heartbeat is just one way. The general rule is that there is no way that works all the time. Dan Wing: Absolutely. With networking nothing is sure to work. Christian Huitima: Especially with NAT. It is unclear whether the best solution is heartbeat or fast resume. Dan Wing: Should we solve that? Or just pick heartbeat? Or just fast resume? Eric Rescorla: The failure mode if unsure about the state of the NAT or the server is that you send packets out and don't get anything back and timeout. Is there a guarantee where the NAT is confused that no packets come back at all? Dan Wing: No. Eric Rescorla: It is very different to have fast-resume with fast-fail than fast-resume with slow-fail. Dan Wing: Anyway we need to pull that out and put it into a separate document.... Dan Wing continues and finishes. Paul Hoffman: I think that we can publish the flows draft when we understand it. I think that when we talk about flows that we wait for TLS/DTLS 1.3, because we know that there is significant enough change that it is worth waiting. Sara Dickinson: If you isolate from the document the message XXX part. How much is DNS specific. It looks like it could be generalized. Maybe better placed in the TLS working group. Did I miss something? Dan Wing: Currently that is true for what it says right now. We don't have anything that says how DTLS fails over to TLS. I would like this document talk about DTLS. Sara Dickinson: Failover is about DTLS fail to TLS. Dan Wing: Actually failing back and forth from DTLS to TLS. Sara Dickinson: It might be better in the TLS working group though. Eric Rescorla: I have not read the draft so I cannot comment. Paul Hoffman: I would support it staying here. There are not other places where people have said "we might do it over TLS or DTLS". I would want the TLS people to look at it and make it right. Warren Kumari: I am a little concerned we don't have the right set of knowledge. Paul Hoffman: Not currently, but we also don't have a draft. Also hopefully TLS 1.3 will be done and they will have time to look at this. I am not worried that we will not have enough review. Paul Hoffman: There is also a workshop (TRON) to get people who are not active in the IETF to look at TLS 1.3 and tell us if we got it right. If this is a working group document by then, I am sure some eyes at TRON will look at it. Dan Wing: There is also presumption that people want this as a working group document. Warren Kumari: How many people have read the document? [About 5 or 6 hands] Warren Kumari: How many people will read it? Eric Rescorla and Christian Huitema raised hands. ---- The way forward... Warren / Tim 15 minutes Warren Kumari discusses the plan. Asks for people to read the DTLS document. Toerless Eckert Christian Huitema Sara Dickinson Stephane Bortzmeyer Warren Kumari: What is the next step? Stephane Bortzymeyer: Recursive to Authority. More and more people will have their own resolver due to lying resolvers (legal reasons). But if you run your own resolver you are not behind a large, shared cache. It is very important that we address this step. Daniel Kahn Gillmor: I would be very sad if we don't try to tackle the authority resolver step. Also operational guidance for people who want to deploy this. Daniel Kahn Gillmor: I know it's not my place to ask for adoption for other people's drafts, but EDNS padding should be adopted somewhere. Then if someone wanted to do good research on what good padding policies are they could do that. Warren Kumari: Do the authors want it to be adopted? Allison Mankin: I agree strongly that we should work on this. Mark Andrews : Another problem is that people don't trust recursive servers. Tim Wicinski: I think we should be chasing performance, and make a testbed on the TCP stuff. Warren Kumari: That seems interesting and useful but not necessarily DPRIVE. Tim Wicinski: I don't think we Tim Wicinski: As co-chair of DNSOP, the padding will stay here. Paul Hoffman: I think it is premature to deal with recursive to auth until we have some experience with it. The assumptions that people are making about round trips from recursive to auth need work. We should get implementation experience. The biggest question for recursive to auth will be TLS or DTLS. Shane Kerr: I think that any recursive to the group will look a lot , why wait Paul Hoffman: We needed experience to get going. Say we do push it out and we sort of get it wrong. If we make a mistake on authoritative servers it will be a much longer deployment cycle. I would like to feel more confident about that one. I don't want to wait a long time. Allison Mankin: I have been think we have a window of opportunity. People get used to privacy violation - we are aware of that now. Warren Kumari: It sounds like people are interested and willing. ---- Performance art / interpretive dance. 5 minutes https://www.youtube.com/watch?v=QHZR9SA5pOg