[ The chairs wish to thank Aziz Mohaisen for taking minutes ] Meeting: DPRIVE meeting Monday, March 23, 2015 What: DPRIVE When: MONDAY, March 23, 2015, 1520-1650 Where: Venetian Administrivia --------------- Warren / Tim 10 minutes Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dprive-4.pdf Chairs (Warren speaking) Note well (the slide wasn’t there, but everybody agreed that they had seen it before) Status update: DNS privacy consideration document was submitted to IESG for publication Plan for this meeting: Need to decide on way forward and get one of the three documents to move forward. Perhaps will choose multiple and one of them will likely not move forward. ================================================= Evaluation of Privacy for DNS Private Exchange ----------------------------------------------- Allison Mankin 10 minutes Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dprive-5.pdf Notes: Asked for adoption of the draft in the WG upon implementing some updates proposed by the WG (mainly Stephane B.) Issues 1 addressed in the draft passive pervasive monitor. Active monitor: we define this to allow people to talk precisely about what kind of attackers they are defending against. Quick key overview of the system model Quick key overview of attack model, system model, mechanism parameters, privacy goals, and evaluation of the various techniques. Issue 2 (TODO): add the broker into the system model so that it’s easy to address some of the issues not being captured in other systems. Expand system model – monitor that is in systems. Fill the TODO (including evaluation templates) Comments and Questions: Stephane: it’s a good exercise to read the document and use by others. Please go ahead and do that. Marcos: it is striking that the problem statement does not use this terminology. It’s confusing. I know this is not the problem statement; but we should be consistent. Stephane: we should be consistent with other documents, and be careful not using attacker by eavesdropper and observer; the essence of RFC 6973 Andrew S: if the terminology draft is that important, we should get it out as soon as possible so that we are consistent across different documents (including this one). ====================================== Private-DNS -------------- Phillip Hallam-Baker 20 minutes Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dprive-6.pdf Notes: Objectives: Privacy: Traffic analysis resistance and Confidentiality Authenticity: eliminate response spoofing, and guarantee user’s choice of resolvers. Service: protect resolver and protect third parties. Constraints: must work in 100% network circumstances, cannot increase latency, and a modest performance penalty is acceptable for dealing with edge cases (they are driven from OCSP experience). Browser vendor question: I am very wary of comparing to OCSP for performance guidelines. Philip: when I suggested a protocol for doing the OCSP, they (browser vendors) said these are the requirements to consider. Architecture: a long-term connection to your DNS service providers specified by the users; json-format that uses TLS to establish a connection to the server. Connection life is determined by the needed property; short for better privacy Comments and Questions: Allison M comment: there’s a lot of similarity in the long/short circuit time with Tor, and certain privacy concerns are there – an attacker can correlate. Willem Toorop: the end user would use their DNS providers and stick with it. However, most places don’t have web DNS to support this. Philip: it’s a requirement and you have at least to have that as an option. The way it’s done in this work is that DNS privacy protection is being bundled with antivirus. Resolution protocol: on top of UDP; simple session layer with one packet request and 0-16 response packets, where every message is authenticated and encrypted. A message can contain padding to guard against traffic analysis attacks. TLS wrap above the packers in HTTPS or TLS in addition; provides a fallback protocol with near 100% connectivity. Eric from Mozilla: circle to the example where a user can choose his DNS provider in the coffee shop; however you have to view your adversary as a passive or active attacker. Answer (Warren): we aren’t decided which adversary model is the one considered in this context. We assume that the user will perhaps use one DNS service and stick with it. Applications: anonymous use where requests are not authenticated and enterprise connections come with other features. Complexity strategy: resolution protocol is very simple, framing is described in 2 pages using the TLS schema syntax; Open questions: Is there an additional layer for crypto? Can easily add an intermediary layer of crypto, and waiting for the CFRG ECC outcomes. Questions: Andrew: based on the architecture you have, we could be doing it anyway with DNS 2. Why don’t just do DNS 2? Philip. I mentioned that I am compatible with DNS 2; this work provides an escape path. Jon from NLLab: the service is provided with antivirus, so why do you bring it here? Philip: we wish we could this over standard. Paul Huffman: the charter says “this wg would provide confidentiality between users and DNS resolvers”. =============================================== Why not progressing my stand-alone proposals Paul Hoffman 5 minutes Slides: None. The drafts are expiring and going away. A dual system that I will describe is going to cover some of the ideas in some of the previous documents. ============================================== draft-hzhwm-dprive-start-tls-for-dns -------------------------------------- Allison Mankin 20 minutes Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dprive-0.pdf Notes: Draft presentation (DNS over TLS) Protocol overview Provided an overview since things have changed from the last IETF meeting. Design choices The DNS infrastructure is still same, but the client needs to be modified some middle boxes block unassigned tcp ports, but some middle boxes still block tcp/53. Our proposal works with authenticated and opportunistic tls Eric: three observation; if you get the ip address through dhcp, then validating the certificate cannot help you very much; 2) you can slightly enhance the interface by telling the resolver some additional information and give it a certificate (or a domain name; fingerprint; etc.); 3) if you are going to the opportunistic and not opportunistic path, then you should provide a way to fall back. Paul (Answer for the last point): it’s unlikely that someone would be connecting to a computer for any reason, and not having access to DNS. Continuing the discussion (additions since the last version): It’s now a two step process: try a port-based, and if that does not work go to TLS Added more about motivation throughout the document Documented a few more open issues, and added Paul as a co-author. (Switching to Allison Mankin) We have an implementation out there, and the implementation is not changed. We have a lot of experience with DNS over TCP. Note that there is no reason to open and close TCP between stub and recursive; they are long lived; tuning matters – a few seconds as opposed to few packets Peter: the part with the initial synchronization should be up for some discussion. Allison: yes Peter: what is the assumption of the end system that uses the resolver? Demon, applications using stateless resolvers, among others (end-points). The number of TCP queries might be a bit bigger than one can envision here. Allison: there is the dns-op document which specifies when a client is using tcp; it implies that a client would reuse the existing solution. Paul Huffman (follow up on the answer): we don’t have a model; it could be a model, but it’s not part of the specs. Paul (not Huffman): we use encryption anyway, so I am not sure what the document adds. I am a little confused; as I am not sure if this document is addressing any issue. John Heidemann: there is a number of people who use public dns, where they don’t have vpn. West (?): having a problem finding out how this is going to solve bootstrapping problem for authentication. Philip: TCP can do anycast really badly. Changing that ups the cost immensely. The other way is to do with deployment; opportunistic shouldn’t be something we should architect for. --: scaling TCP (having 3 browsers on the same host) is not known to be scaled well.. --: blocking tcp is different from blocking unauthorized tcp; middleboxes do intelligent decisions and they may fail, but unauthorized tcp is blocked in anyway. --: is there any encryption over UDP? Allison: the next talk. ==================================== draft-wijngaards-dnsop-confidentialdns Glen Wiley 10 minutes Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dprive-1.pdf Uses both TCP and UDP; algorithm agility, cacheable IPv4and6 on port 53 Not adding much latency From the prior version, we simplified a bit; others are increasingly complex. Also encrypt dns rcode and optional authenticated keys with DNSSEC. Requires an RRtype ENCRYPT; there’s rollback if encryption fails for any reason. Comments and Questions: Question (Tim) is it tested? Glen: only in our dreams Paul: I don’t think this is TCP/UDP in anyway. The other issue, with the current specs, you are not doing a DH (he meant the diffie hellaman key exchange) to get a symmetric key, and if it’s used but it’s not forced so the client has to do more computations than TLS. I am not convinced on that we can do it over UDP. Glen: those are things that are worth looking at. Philip: you don’t want to do any ECC / public key work before getting authenticating of source ip addresses. Before you forward your packet to an A; you are forced to do some public key operations, which opens a window for a denial of service attack. -- (question): this is the first attack that smells like DNS; with the other solutions that do lightweight authentication (cookies), I think this can be made to work. --: what’s the plan for addressing head of the line blocking. Glen: we didn’t try to solve some of the specifics, so this is something to look at. --: who is going to switch to TCP? Allison: 5966 explains that you can pipeline. ======================================= The way forward… Warren / Tim 15 minutes Slides: http://www.ietf.org/proceedings/92/slides/slides-92-dprive-3.pdf Notes: The way forward. One draft or many? This doesn’t have to be final as things may change as we go forward. Multiple options: Private-dns Draft-hzhwm Draft-wijngaards Hums: Adopt 1 Adopt multiple Don’t have enough information so we can decide Peter: What does it mean that you don’t know enough? Warren: Go home, read the drafts, and vote later on the mailing list. Warren: the first hum will be “I would like to adopt a document”. “I would like to adopt multiple documents” “we cannot make a decision at this point” No conclusion; spend some time on the mailing list. Question: is there any way to do a binary decision on any of them. Yes: yes, we can do that. --: I am more interested in having this problem solved than having my work accepted. I want those who adopt to come along and accept whatever we agree on. Warren: having a select few of people to decide the way forward is not the way the IETF works. From Christian Huitema, Microsoft: why I personally like option B (hzhwm)– it’s the one the makes the least possible innovation. Voting and hums: Overwhelming vote in favor of hzhwm Overwhelming hum against private DNS Neutral hum for confidential DNS