Minutes IETF104: dprive
minutes-104-dprive-00
Meeting Minutes | DNS PRIVate Exchange (dprive) WG | |
---|---|---|
Date and time | 2019-03-29 09:50 | |
Title | Minutes IETF104: dprive | |
State | Active | |
Other versions | plain text | |
Last updated | 2019-03-29 |
minutes-104-dprive-00
DPRIVE WG March 29, 2019 Brian Haberman and Tim Wicinski, chairs Minutes by Paul Hoffman Things on the slides are not reproduced here Phase 2 requirements and milestones; Benno Overeinder and Alex Mayrhofer Question 1 (hard requirements) DKG: List of SHOULDs/MUSTS different in the group Scope of the question is odd Authoritative name server MUST have its identity validated Need to sort out auth mechanisms Stephen Farrell: Would like a direction towards suggestions Joe Abley: The requirements need to be useful as requirements Should be ulitmately be published Should be useful requirements Karl Anderson: What do MUST/SHOULD mean in an unpublished document Sean Turner: Agrees with Steve Watson Ladd: Some sort of distinguishing Ralf Weber: We have done efforts to having the data in DNS secured Question 2 are we set with DoT Paul Hoffman: Yes Sara Dickinson: It the requirement that we will use no other protoco than DoT? Would we look at better protocols? Yes, but it is not a requirement Peter van Dyke: Doesn't want probing, make it discoverable and a small set Manu Bretelle: Seems OK Eric Kline: Need a mandatory minimum, DoT seems fine Eric Nygren: Wants a way to go to DoQ Puneet Sood: Seems fine Watson: Don't make your own protocol Petr Špaček: No probling Question 3 end user signaling DKG: Put this off Manu: This will be complicated Stephen Farrell: Useful to think of, but keep off critical path Peter Lexis: What would end user do with this info Alex: Green padlock Christian Huitema: Keep it simple, no way to know if the resolver is lying Joe Abley: Should the user be able to signal that it wants signaling Wasn't suggesting that it was easy or sensible Ralf: Recursion from cache is nearly impossible Wes Hardaker: In the HTTPS world, for the user to act on web content True with the green lock DKG: Signaling to or from user is super-complicated Failed to do this in the IETF when it was much simpler Dan York: Will the end users even care? Will anyone do anything with this? If no one is going to use it, just move on. Eliot Lear: Overarching question for IAB: what sort of end user signaling is useful Ekr: Can't imagine what the client would use with the signal Brian Dickson: Policy discovery Should go to the application, not the user Sara: Likes client signal to ask recursor to only do a query privately Other questions? Stephen: Is the goal to be strict or opportunistic? BrianH: Need to figure out where the pieces that people have proposed fit in; later PaulH: Please keep comments on the mailing list Ekr: Likes issues on GitHub Stephen: Keep non-editorial on list Ralf: Keep on list Dan: Is this going to become a draft? Different way of working, this is not really a draft Benno: Use to structure drafts and start a discussion Dan: This is now a stealth document Brian: Could be a document, or a link on the charter Ekr: Drafts are cheap Lars-Johan Liman: Draft Update on DNS Privacy Considerations and Operational BCP; Sara Dickinson Ekr: Are you saying be running unless you're doing this? Sara: If you say it is a privacy service Ekr: Red exclamation looks bad How will you handle neutral things like blocking Sara: Try to map into compliance Ekr: What is the policy setting / what do they do / does that disagree Sara: Maybe will add tests from multiple vantage points Also add over TLS Stephen: Multiple categories of blocking Jeff Hodges: Look at netalyzer at Berkeley, might be synergy Allison Mankin: Having a BCP on this is valuable This group can do that Rich Salz: Would like to see advice for CDNs BCPs are for a point of time, things change over time Joe: Should be published Defines terms that are useful to site Dan: Split out the DPPPS thing Useful to put in front of lawyers Christian Huitema: Some of this is client-side recommendations Recommendation of "don't break clients that are doing the right thing" Client BCP would tell how to choose a resolver, which gets tricky Alex: When would move these documents to DNSOP? When are encrypted protocols normal protocols? BrianH: CDN providers should sent text for this document Will ask for review in DNSOP, keep the document here Watson: Shouldn't this be for all DNS operators? All DNS operators be using encryption DNS Privacy and Applications; Vittorio Bertola Ekr: Introduction does a reasonable job Recomendations reflect one point of view Cannot imagine get any consensus Trim down to what is making upset, add in why peole want these Stephen: Agrees with Ekr Document is not written objectively Nothing should be done with this until more evaluation is done on bigger picture Martin: Find someone who is implementing this as a co-author This is very much like throwing stones Long way from finding balance Good list of concerns being articulated There's always one more thing that pops up Vittorio: Welcomes co-authors Stéphane: Surprised by example Not in DPRIVE's charter Many issues are unrelated to privacy Some are in scope of IETF, some are not Asking for consensus is wrong Split this into managable issues, don't do laundry list For each, is it an issue for the IETF Sara: Good starting point for discussion Different types of clients (humans and applications) for two dimensions Restructure: identify the threats and give mitigations Watson: Recommendations are acceptable This is a broader issue for larger WG Vittorio: Not so easy to separate the discussion Certificate Discovery for Recursive to Authoritative exchanges; Manu Bretelle Paul: Different SPKI in Name could remove a red block Joe: There is no real way for name servers to update certs well Watson: Signaling that you can do DoT vs. authenticating Keep them separate Manu: Do9 gets signal from parent PeterVD: Some resolvers are broken for broken DS algorithms Manu: Other ways for DS to signaling Wes: Parent-child synchronization makes some of these a non-starter Ralf: Agrees with Wes Solution should be a child side Should require DNSSEC Alex: EDNS0 option? Manu: Can be intercepted and dropped Bootstrapping to discover DoT and DoH servers; Tiru Reddy DKG: This strikes as room for implementation error Ekr: What information am I coming away from Tiru: Will let them connect to local resolver Need a certificate for EST server Richard Barnes: Switch between public internet and managed enterprise network mode Tiru: If you are using MITM, this is not needed Michael Richardson: This is the thing that imprints on the device Ekr: Is there a wired communication path? Tiru: User has authenticated to the network Watson: Why are you TLS SRP Stephen: Are you used to EST? Seems weird to use that to get DoH Warren: Confused about deployment model How does my device know not to use the Starbucks one PaulW: Orthogonal to the IPsec client that connects to the client Read all limitations on the Split DNS draft for IPsec Matt: This is a malformed problem statement Network security services don't need to treat DoH and DoT the same We want people to DoT and DoH Names hostile users and applications Won't solve hostile applications through configuration Won't solve hostile customers through more management Richard: Tussle There is a use case in here Figure out what the user experience you want to create BrianH: Asks about how many have read and think in scope Martin Thomson: Related to work in the DoH WG Could need to understand the mechanism Frightening mix of acronyms Could be simpler BrianH: ADs should help coordinate where things like this should happen