* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dprive Status Pages

DNS PRIVate Exchange (Active WG)
Int Area: Suresh Krishnan | 2014-Oct-17 —  

IETF-104 dprive minutes

Session 2019-03-29 1050-1250: Congress Hall 2 - Audio stream - dprive chatroom


minutes-104-dprive-00 minutes

          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
                                          Need to sort out auth mechanisms
                          Stephen Farrell: Would like a direction towards
                          Joe Abley: The requirements need to be useful as
                                  Should be ulitmately be published
                                  Should be useful requirements
                          Karl Anderson: What do MUST/SHOULD mean in an unpublished
                          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
                  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
                  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
                  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
                                  Won't solve hostile customers through more
                  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

Generated from PyHt script /wg/dprive/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -