Minutes IETF104: dprive
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