DNS Privacy Exchange (DPRIVE) WG IETF 99, Prague Tuesday, 18 July 2017, 09:30-12:00 CEST Chairs: Tim Wicinski and Brian Haberman Minutes taken by Paul Hoffman Text from the slides is not reproduced here draft-ietf-dprive-dtls-and-tls-profiles Give it a Review! People need to review and comment Want to get the ADs to remove their DISCUSSes Stephane Bortzmeyer; Most of the IESG remarks were on details DHCP was not important in the draft The draft didn't change a lot Francis Dupont: Maybe reach out to the various review teams to re-review draft-ietf-dprive-padding-policy: Alex Mayrhofer Daniel Kahn Gillmor: Analysis is "what percentage of query/response pairs is in the same-size bucket" Adding random length doesn't improve benefit Christian Huitema: It's harder to impelement random padding correctly Daniel: DNScrypt uses a nonce in the query, and he used that in the research Christian: Don't merge the documents Padding strategy depends on which transport you use This is find for UDP, but maybe quite different for TCP or other transports Alex: What other transports are in scope? Christian: Padding also helps protect from DoS Will send text to the list Daniel: Keep it as a separate draft Patches in many clients and servers Updating resolvers with new defaults is easy Shane Kerr: This seems like a good policy Maybe want to hear from crypto folks Stephane: Document is OK and we should move forward Will do a review Tim: this should be Experimental Need more reviewer Olafur, DKG, Sara, Christian, Shane, David Lawrence agree to review Wes Hardaker: DNSOP is working on extensions that will change sizes Brian: Do the slides include how the data was analyzed Daniel: Only in presentation format Happy to share the programs used to analyze Can run the code over datasets from other recursive resolvers draft-huitema-quic-dnsoquic: Christian Lots of people know what QUIC is Phill Hallam-Baker: Proposed something like QUIC before QUIC QUIC lets him have an idempotent server Can make recursive resolver completely idempotent? Chistian: We need to have some state for crypto, but can we reduce the state needed? Because this comes in application layer, you can try new things more easily ?1: Current way QUIC is specified is that one UDP packet maps to one QUIC packet Proposal to make several UDP packets in one QUIC packet Ian Swett: Likes the proposal for QUIC Christian: Has data about current DNS works in here Ben Schwartz: Wants to be able to multiplex this over a single port Christian: There are use cases for DNS-over-HTTP-over-QUIC for stealth Flip side is that servers need a full HTTP stack, with tradeoffs Ben: Wants this in parallel, not necessarily in HTTP Christian: Allow multiple ALPNs, Alex: Joke about "QUIC over DNS" Reminds him of encrypted RTP problem from ten years ago Worried about proliferation of number of transports ?1: Doesn't QUIC seem heavyweight? Would prefer a simpler protocol that is DNS-specific Christian: We get implementation experience by working this out Andrew Sullivan: QUIC is pretty promising for our use cases Nervous about how this is framed as stub-to-recursive, and recursive-to-authoritative Uncomfortable to make this split Christian: two reasons for QUIC: privacy and performance Half of queries to resolvers are from cache Thus need to think about UDP retransmission for responses that take longer Tradeoff of efficiency and performance Andrew: Retransmission hurt on the server side as well Phill: There was a proposal to do a DNS-specific transport QUIC is becoming new SSH Few proposals for new crypto protocol We are going to change the DNS protocol no matter what The spec for DNS is awful, and doesn't say everything that it needs to Doesn't say what the length of responses QUIC will remove that limit Wants to see documents with traces so he doesn't have to read the QUIC documents Olafur Gudmundsson: There is difference between the different hops Disagrees with Andrew David Lawrence: Agrees with Andrew Main interest is in authoritative servers Doesn't think this is useful to split Alex: This is interesting because we can look at things that are not TLS for maybe ten years from now Stephane: If we follow this path for DNS encryption, two problems DNS client needs to make a choice Marketing / PR to tell folks which to use Alex: Will run on UDP/53 forever due to NAT64 Tim: QUIC is a work in progress We're getting ahead of the horse Christian: This work helps the QUIC development We can do experiments and comparisons that can help us inform the discussion Alex: We would need a significant recharter if we're going to change DNS Terry Manderson: It's great to have the discussion as long as it is not siloed here Keep working, keep thinking draft-dkg-dprive-demux-dns-http: Daniel Christian: If you have a different ALPN, this will change Dan: ALPN differentiates between H1 and H2 here Demonstration of how to do this today Christian: This allows to block after first packet ?2: Distinguishability still is a problem because of SNI Daniel: Doesn't hide server name Suspects that most network adversaries is Phill: What is the proposed final status? Daniel: Wrote this to make it visible, but hasn't proposed that the WG adopt this Web services use HTTP to expand the number of ports Better to do this over QUIC Shane Kerr: This is not a terrible hack Reasonable approach Maybe doesn't belong in this group Martin Thompson: Just declare victory and don't publish as an RFC Patrick McManus: Why can't you just speak HTTP? Daniel: Existing DNS over TLS clients don't need to be modified This motivates the other work for long-term potential Eric Rescorla: Requires colocation If the host only does this, it become obvious Historically, this puts handcuffs on both protocols The number of deployed DNS-over-TLS clients is low, so add stuff to the clients Why is this only good for DNS? Andrew: Agrees with Eric Disagrees with Martin We should be writing this down Using accidents of the internals of the protocol to determine the transport Danial: This is a functional way of hiding a metadata to adversaries We can't be burning this casually Ben: If we don't move forwards with DNS-over-HTTP, this is what you will end up with Phill: Disagrees with Eric's rant HTTP servers are required to look for "HTTP/1" Could use "GET DNS" instead Christian: There are many ways to multiplex The advantage of the .well-known is that everything is encrypted Multiplexing based on port doesn't work well because it allows censorship We could instead use ALPN if it is hidden using tricks like are used for SNI We are dealing with both privacy and censorship We can change TLS to encrypt the token used for demuxing Martin: This is a threat to the architecture Don't do this again The point is well-made, but it needs to be clearer Tim: People got too excited by trying to solve the problem, not seeing that there was a basic problem Drive future conversations Move your metadata into the envelope Brian: Maybe publish this with "don't do this" Daniel: Won't do that as long as network operators are blocking traffic they don't understand Paul Wouters: We are doing the same think with IKE over TCP Were told "don't mention port 443" Doesn't think that is useful What's next?: Tim How do we get more deployment? Sara Dickenson: See https://dnsprivacy.org for lists of who has adopted Not much seen in clients Maybe will show DNS-over-TLS on anycast Maybe add traffic levels and usage Shane: This isn't DNS Privacy Ops Tim: Wants to get operational data Maybe not in the current charter Maybe add DNS-over-TLS to their open resolver Need to get it pushed into the components they are using It's going to take a long time Sara: Challenge the idea of waiting for data on stub-to-recursive before we start recursive-to-authoritative Tim: We should start thinking about it because it will take a long time Ben: Cares a lot about client side Time delay measured in years for clients to be able to use the new code Tim: doesn't feel that it is a failure Alex: Ran some analysis for adding TLS to their authoritative Came up with 8x as multiplier for the amount of resources needed Terry: Importance of measuring is for the next question Shane: We saw earlier estimates of adding TCP is 6x But a lot of the overbuilding is for protecting DDoS over UDP Tim: Can people share their estimates for TCP Dan York: Measurements are important Help make the case for deployed Alex: If someone has grad students, try replaying actual traffic Sara: There are other problems with recursive-to-authoritative that are not about performance Stephane: There was very little discussion of the step 2 draft Maybe have a draft proposing one solution Would be to use DANE to publish certificate in DNS Daniel: Supports work on recursive-to-authoritative Warren made slides of DNS usage