Liang’s talk - IP address encryption as a complement to DOH or DOT, no change to DNS, no changes on endpoints. Can we get privacy benefit from this
Scott’s talk and DKG’s talk - there’s information leaked above recursive, but Scott asks if it’s operationally feasible for the auth operator to do encryption, whereas DKG takes the view that it needs to be
Open discussion ->
DKG asks Scott about the TLS vulnerabilities:
are they vulnerabilities to the operation or to the cryptographic promise of TLS? Characterize the attack service better for authoritative servers considering deployment
Scott says - we didn’t dig deep into this. Different vulns have different risks. This is a place where studies are important.
Benno - Scott, you did an analysis and a handful of others did - is there an overview of the operational impacts studies? Who should be doing this? Where should this information be shared?
Scott - has some things happening along those lines - we do protocol design in the IETF, but not how it really works. IF we make a mistake in ops for COM, NET, A and J roots, that’s very bad. Scott will be talking about this during upcoming DNSSEC Workshop at ICANN. These aren’t going to be resolved in the IETF, needs to be where the operators are.
Allison - there are many types of SLD. My org is talking with our vendors - we have different tradeoffs than a TLD or an infrastructure SLD
Scott - characterized the enterprise domains as smaller or lower risk
DKG points out that you could safely try at root and TLDs too by having some instances
Jim Reid - don’t forget that if enterprise domains are broken, there are also some dire consequences. A lot of ISPs or others will think it’s too hard and it will result in more aggregation and consolidation - toss it to Google or another third party
Wes Hardaker - didn’t write down this question…
Paul Hoffman - just to be clear, from my comments in the main session, I’m very hesitant for us to say that “in order to get to this place, these people must do something” - we should not link privacy decisions to someone doing enough of what’s needed. Just don’t assume that the resolver operators will do the right thing. Even qname minimization is still dicey and experimental. If we want more privacy, offering many, letting people try it, find out how it works by measuring it. Don’t discourage anyone to try what works for their need. We know there are TLDs that care a great deal to be very privacy preserving. He notes that the increase in TCP is a big thing. At root and typical auths, the use of TCP is about 5% and it will go to 50% or higher.
From the Zoom chat:
dkg to Everyone (3:48 PM)
fail-open protocol defaults are terrible long-term. but we currently have a open-all-the-time default for recursive-to-authoritative
Paul Syverson to Everyone (3:48 PM)
and/or downgrading attacks.
Jim Reid to Everyone (3:49 PM)
@paul where are the trade-offs documented so informed decisions can be made? if there’s no guidance…
Jim Reid - not compel, but give people good guidance. Where is that to happen?
Paul Hoffman - we tried to do this in DPRIVE, and it became unreadable to the operators. Ask Benno to comment: for a lot of operators, the best source of information is their vendors.
Benno - Thank you, Paul
Wes Hardaker - follow-on topic - splitting out secure vs. insecure protocols - we should figure out which operators pehaps split TCP vs UDP. We (ISI) have created some infrastructure with NSF funding, reach out to Wes for help setting up experiments
Benno - wrapping up, any other last topics
DKG - I wanted to call out the concerns that Paul Syverson raised about fail-open. We are pretty good now at moving form always-open to fail-open to something that can be locked down. STS is the example. Learn the resource management parts with the opportunistic experiments.
Benno - three things to wrap up
Notes on the three breakouts (when we are back in the plenary)
Measurement - Sandra - discussed protocol designs and end-user education as a continuation of the earlier discussion
Civil Society and Usability - Gurshabad - discussed balkanization - can we make this cost? Also discussed user education, there a priority is not to overload the user with info and making them not fear they will break their Internet
Novel Work and ADot - continued from session. He shared the three points above.