Thanks again to Mr. Paul Hoffman for putting together the draft minutes of
the meeting.
Because of the Phase 2 discussion had several useful points, I plan on
going back
and listening to the audio and confirm with the authors on that portion to
make sure we picked up everything.
The minutes are here.
https://datatracker.ietf.org/doc/minutes-106-dprive/
If you see anything that looks incorrect please drop a note to the chairs,
or send a pull request:
https://github.com/DPRIVE/wg-materials/blob/master/dprive-ietf106/dprive-ietf106-minutes.txt
Thanks for a productive meeting
Tim/Brian
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
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
