Minutes IETF101: dprive
minutes-101-dprive-00

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