DPRIVE WG Wednesday March 21 2018 Brian Haberman and Tim Wicinski, chairs Minutes taken by Paul Hoffman Text from the slide are not given here No changes to the agenda DNS Privacy for Operators BCP, draft-dickinson-bcp-op Roland van Rijswijk-Deij Francis Dupont: Has a concern about client-subnet Roland: Needs to be discussed for the new draft Sara Dickenson: Earlier draft is in AUTH 48, but says what policy to use Ted Hardie: May be look at port considerations with respect to port 443 Ted: More discursive, more contextual approach would be better Wants a ranged approach with more contextualization Also say "it would be nice if you just turned this on just in general" "Here's the minimum thing you can do to get X" Stephane Bortzmeyer: Very few people have experience with setting up a DNS privacy server Maybe not best practice Amelia Andersdotter: Terminology doesn't conform with earlier RFC Why is there a distinction between monitoring and logging? Roland: they have to do with each other Should describe the "state of the art privacy" Stephen Farrell: Good to start the work here Maybe begin it here Roland: Maybe want this as a living document, Thus maybe do it in RIPE Jim Reid: Some things here are premature Seems like boiling the ocean, limit the things that you want to achieve It could become so generic to become useless Peter Koch: Good starting point IETF should not do policy debates because they would never end Maybe just enumerate the options without picking one Roland: Making it less prescriptive better? Peter: A different venue (not clear which) would be better for the privacy considerations Warren Kumari: Various privacy orgs view the GDPR differently Needs to be clear in the doc that turning this on is good even if you are not a "privacy server" DKG: Thinks this WG is a good place to do the work even though it will be tough Maybe start with one practice is good, but it can be extended Let's start the conversation now Maybe add a section on aggressive prefetch for privacy Many people had read the document Many people thought that pursuing in this venue was OK Using Bloom Filters to Collect DNS Queries Roland van Rijswijk-Deij Alex Mayrhofer: Can the bloom filter be saved to file? Roland: Yes Edward Deen?: Lose the cardinality of events; can this be fixed? Roland: There are some ways that can work Whether a query occurred is more important than how often Mukund Sivaraman: How will the author use the names will be used because there is risk of false positive Roland: wants to know the impact of false positive Christian Huitema: Worried that an attacker could choose names that would cause collision and hide DKG: Use a random salt DNS Resolver to Authoratative, draft-bortzmeyer-dprive-resolver-to-auth Stephane Bortzmeyer Ted: Why rely on DANE, maybe use certificate from ACME instead Stephane: Hadn't thought of it, but doesn't like CAs in general John Dickenson: Maybe authenticate the zone with DNSSEC public key Wes Hardaker: Likes this direction, doesn't like the happy eyeballs idea Stephane: Maybe send them one right after the other Bad for priacy Wes: can send a query for DANE record to get both Stephane: may have port 853 blocked Jim: Doesn't want to recharter until we have more operational experience Don't know the impact on users More interest in DOH than DPRIVE Need feedback from the authoritative servers to know the impact Wants modeling and analysis and empiracal evidence Opening up CPU attack from crypto Stephane: Maybe have multiple servers with dnsdist DKG: Supports recharter in this direction Advancing a draft like this will encourage operators to come forwards to get input Phill Hallam-Baker: Skeptical due to caches Only seeing small set of traffic Worried about traffic analysis vs. encryption Stephane: lots of requests have privacy information Padding can fight traffic analysis Stephen: Likes what DKG said Try some tests before going forward Ben Schwartz: Many authoritative servers share addresses Doesn't like some of the ideas, but should go forward Olafur Gudmundsson: Likes this idea, but not sure we should do this now Coalesce many queries Sara: Suports DKG comment to work on this now Tony Finch: +1 to Ben WG Re-charter Chairs Tim: We might recharter to get more data It's OK to recharter even if it doesn't get all the way to the root Get proof that it will scale Shane Kerr: Work items look good In an experimental space Maybe doesn't fit well into IETF WG model Maybe IRTF? Terrry Manderson: Thought about that Maybe in the WG, maybe in IRTF Alex: Happy with the first two bullets as experimental, not third Maybe IRTF for third Petr Špaček: Wants the WG to do this work Didn't respond earlier because no time; silence doesn't mean lack of interest Matt Ford: MAPRG is actively soliciting work for input Tim: Will talk to IRTF and MAPRG