* 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: Éric Vyncke, Suresh Krishnan | 2014-Oct-17 —  
Chairs
 
 


IETF-106 dprive minutes

Session 2019-11-22 1000-1200: Collyer - Audio stream - dprive chatroom

Minutes

minutes-106-dprive-00 minutes



          DPRIVE WG
          IETF 106, Singapore
          Chairs: Tim Wicinski, Brian Haberman (remote)
          Minutes taken by Paul Hoffman
          Text from slides not given here
          
          Admiistrivia
          
          Adaptive DNS: Improving Privacy of Name Resolution
          draft-pauly-dprive-adaptive-dns-privacy
          Tommy Pauly
                  Tim: Which list for discussion?
                  Tommy: Both
                  Brian Dickson: GoDaddy will turn on DNSSEC signing for all
                  customers
                  Alex Mayrhofer: Get into a grey area of what is recursive and
                  what is authoritative
                          We should be careful
                          Could instead use a URI RR
                          Tommy: URI RR doesn't let you say what the semantics of
                          the value is
                                  Do we want to put DoH in front of main
                                  authoritative servers?
                          Alex: Maybe like hosts.txt made modern
                  Petr Špaček: Custom made Tor network with DNS on top
                          Tommy: It is possible to build to deploy with bad privacy
                          prolicies
                  Stephen Farrel: Maybe being too optimistic
                          How will a client choose the oblivious feature?
                          Tommy: Looking for an assertion between two zones
                          Stephen: Needs a lot more specification
                  Lawrence Colitti: Duplicated information from the HTTPSVC record
                          Tommy: It is a hint where to go look
                          Gives a way to know which additional domains to look
                          Pushing over HTTP2 at the same time
                          Lawrence: Why tie oblivious with the other parts?
                  Ben Schwartz: We should be thinking more about architecture
                          Likes the idea of mixing recursive and authitative
                          Mode-switching resolver
                  Ralf Weber: Encourage to look into other transports
                  Vittorio Bertola: Does this actually give more privacy?
                          Wants to see more analysis on this
                          Thinks it reduces privacy
                          Tommy: Definitely has a relationship with the name that
                          they are going to
                                  Is about to connect to the same address
                  Tim: Part of this falls into DPRIVE charter
                          Move this here instead of ADD
          
          Oblivious DNS Over HTTPS
          draft-pauly-dprive-oblivious-doh
          Chris Wood
                  Paul Hoffman: Make this oblivious HTTP, do it somewhere else
                  RalfW: Gets scared of network of open proxies
                          Could be abused to kill DoH servers
                          Chris: Doesn't make this worse
                  Tiru Reddy: Why not just use a VPN instead
                          Chris: That is another type of proxy
                  Petr: ?
                  Stephen: Of two minds; maybe just do a Tor-ish thing, maybe a
                  purely DNS thing
                  Mike Bishop: If you proxy is far from the client, you will get
                  worse location information
                          Tor uses consistent node
                  Lawrence: Bear in mind latency
                          DNS is lightweight at the moment, could get overwhelmed
                          by size of TLS
                  Brian: Have you looked at three-way party encryption?
          
          DNS server privacy policy with assertion token
          draft-reddy-dprive-dprive-privacy-policy
          Tiru Reddy
                  Paul Wouters: Seem reinvention of EV certs for DNS
                  Mark Nottingham: Explore why P3P efforts failed
                          Why should need to learn new kinds of consent model
                  Ben: Supportive of idea of geting opaque human-readable
                  information about a DNS server
                          Statiing as a privacy policy takes it into difficult
                          domain
                          Machine-readable formatting is not going to work
                          Trying to reduce legal language to machine-readable
                          language is hard
                          Need exceptions
                          Is happy to have just a URL
                          Tiru: Wants to have both
                  Vitorrio: Finds it useful
                          Will needs to merge with user provisioning
                  Eric Rescorla: How will this work in practice?
                          (Walks through scenario)
                          Web PKI is based on mechanical comparision of domain
                          names, not user comparison
                          Browsers are moving away from this
                  Alissa Cooper: This has been tried in many places
                          Invokes GEOPRIV
                          Need to look elsewhere
          
          DNS Privacy Requirements for Exchanges between Recursive Resolvers and
          Authoritative Servers
          draft-lmo-dprive-phase2-requirements
          Alex Mayrhofer and Jason Livingood
                  Section 4:
                          Eric: Needs to discuss downgrade
                          Petr: Maybe say that attacker that has access to all
                          traffic should be out of scope
                          Ben: Think about CAA, ACME, and DV certificates
                                  Don't create circular dependency
                  Is DoT always required?
                          Ben: Should define protocol and compare to other
                          protocols
                                  We can't tell you to do DoT
                          Eric: We encourage if you know that there is encryption
                          available
                                  QNAME is not in the same equivalence class
                                  Alex: Rephrase to "secure transport" instead of
                                  DoT
                          Wes Hardaker: Not about requirements, but about solutions
                                  Is encryption required? If so, how do we
                                  bootstrap?
                          RalfW: Secure from bootstrapping all the way down
                          Brian: Break out distinct aspects of this
                                  Delegation chain signed or not
                                  Use of DANE needs secure delegation all the way
                                  down
                                  Mandatory-to-implement
                  Trust anchors and security
                          Eric: Please don't get into this
                          Ben: This is not the right level of requirements
                                  This gets into the solution space
                                  Use comparisons for requirements
                          Eric: Many types of settings
                                  Out-of-band settings
                                  Discover keys during chain exploration
                                  Opportunistic discovery: it is what it is
                          Christian Huitema: Scared about circular dependencies
                          between parties
                                  Should be in requirements to not have loops
                          Brian: This is what is agreed on between resolver and
                          authoritative
                          Daniel Kahn Gilmore: Might want hybridized DANE + Web
                          PKI + third parties
                                  Solution needs to be simple enough to be
                                  analyzable
                                  Likes Eric's three-levels
                                  There are time limits on all of these
                                  Happy eyeballs might give you something more
                                  verifiable in time
                          Tim: We are staying away from Web PKI completely
                                  Paul: Disagrees
                          Eric: Something like HSTS with time bounding
                          Daniel: Thinks line is hard to determine
                          Brian: Pinned things needs to honor what's in the DNS
                          itself or it breaks the security model
                  Downgrade prevention and preferences
                          Eric: Doesn't think client specification works
                                  Only thing that can be plasusibly say is here
                                  is DoT and here is not-DoT, need to pick
                                  "I speak DoT all the time" vs. "I speak DoT some
                                  of the time"
                          Ben: Stub should be able to require anything of the
                          recursive
                                  If the stub can't prove this, don't ask it
                                  Gets strange very quicky
                                          What does this mean for recursive cache
                                          If the roots don't do DoT
                                          If the resolver got the root zone some
                                          way
                          RalfW: If the client wants to make an assertion, do it
                          itself
                                  Don't make it more complicated
                          Patrick McManus: One more +1
                          Daniel: Like "require TLS" in SMTP
                                  Think about deployment history
                          Wes: RFC 7672
                                  Has good fallback logic
                          Brian: +1 to what Wes just said
                                  Maybe give guidance for happy eyeballs
                          Patrick: Put more emphasis on secure discovery
                  Discovery
                          Brian: Has to be in the DNS, has to be DNSSEC signed
                                  Linked to the name server
                          Wes: We have a distributed hierarchical data model:
                          why use anything else
                          Eric: In the DNS
                  Tim: Do some updates, then the WG will adopt it
                  Brian: From a high level, make a distinction what the value
                  proposition of mandatory vs. good
                  Stephen: When do you want people put in proposals
                  Brian: If anyone is interested in testing, see him
                  Tim: Open to having another interim in February
                  Patrick: Is this is an interal document
                          Would look differently
                  Paul: NSs that have different operations, some with DoT some
                  without
                  Eric: Don't publish this document as an RFC
                  Brian: Get names from delegation, not from glue
          
          



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