Minutes IETF106: dprive
minutes-106-dprive-00

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