Subject: Re: [dns-privacy] ADoX experiments (was: Re: Intermediate proposal (what I was saying at the mic))

From: Christian Huitema <[email-masked]>
Date: Fri, 3 Sep 2021 21:57:10 -0700

On 8/31/2021 8:36 AM, Bill Woodcock wrote:
>> On Aug 31, 2021, at 2:23 PM, Bill Woodcock <[email-masked]> 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.

Clarification question. I assume that at least in an initial phase, 
there will be clients that do not have a certificate, such as for 
example small networks, or users running their own recursive resolver. 
What would your preferred policy be for those resolvers? Would you let 
them use TLS without client authentication, or would you want them to 
fall back to clear text?

-- Christian Huitema

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 4 Sep 2021 11:23:29 +0200

> On Sep 4, 2021, at 6:57 AM, Christian Huitema <[email-masked]> wrote:
> I assume that at least in an initial phase, there will be clients that do not have a certificate, such as for example small networks, or users running their own recursive resolver.

There probably always will be, yes.

> What would your preferred policy be for those resolvers? Would you let them use TLS without client authentication, or would you want them to fall back to clear text?

Speaking again with my authoritative hat on, my main concern is that they use TCP, so that we can distinguish them from DDoS traffic.  From my point of view, the data I’m serving is all public information, so I don’t care whether it’s encrypted or not.  If it’s unencrypted, I can serve it a little faster, and I can serve more people at lower cost.  If it’s encrypted, it provides more chaff for those who do need encryption, and normalizes encryption so that those who need it stand out less from the crowd.  So I’m neutral on that issue.

With my recursive hat on, yes, I’d definitely like to be able to use unauthenticated TLS, in order to provide a little more privacy for my down-stream users, particularly for the idiots who want ECS.

So, prioritizing from strongest to weakest:

Server authentication:
DANE authenticated
Shared token (TSIG or equivalent)
CA cert
Unauthenticated

Client authentication:
DANE authenticated
Blind signature (draft-irtf-cfrg-rsa-blind-signatures)
Shared token (TSIG or equivalent)
CA cert
Unauthenticated

Transport:
DoT
DoH
TCP
UDP

I’ll reserve judgment on DoQ until it’s a little more real.

                                -Bill