> On Aug 31, 2021, at 2:23 PM, Bill Woodcock <[email protected]> wrote: > > On 8/17/21 8:16 AM, Brian Haberman wrote: >> I believe we need the following: >> >> 3. At least one authoritative server operator willing to deploy the >> experimental implementation, >> >> 4. At least one recursive resolver operator willing to deploy the >> experimental implementation, >> >> Are there any volunteers to start working on details of such an experiment? > > I had, at the outset, said that PCH and Quad9 would be immediately > implementing any ADoX that makes it as far as running code, and in case that > didn’t make it into your notes, I’ll reiterate it now. As I’ve said before, > we STRONGLY PREFER implementations which include TLS client authentication.
I got a couple of questions about that last sentence, so, more words for the
sake of clarity:
From the point of view of an authoritative operator, we would very much like to
be able to authenticate the client recursive resolvers using DANE TLS client
certs, so as to be able to offer them prioritized service during DDoS attacks,
without having to track their multiplicity of changing IP addresses. i.e. we
don’t want to have to track every last source IP address used by the upstream
sides of every last Quad9, Cisco, Google, etc. recursive resolver, and we can
trust them not to share their TLS client cert with DDoS attackers.
From the point of view of a recursive operator, we would like to be able to
authenticate the authoritative server using DANE TLS certs in order to be
assure ourselves that we’re not being MITM’d, but we’d also like to be able to
authenticate ourselves to the authoritative so that we can receive protected
service while the authoritative is under attack.
Right now all this is done with statically-coded IP addresses, which is quickly
becoming an insane headache.
-Bill
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
