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

Christian Huitema <huitema@huitema.net> Sat, 04 September 2021 04:57 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABAC3A18B9 for <dns-privacy@ietfa.amsl.com>; Fri, 3 Sep 2021 21:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDvBAGh7xsTR for <dns-privacy@ietfa.amsl.com>; Fri, 3 Sep 2021 21:57:17 -0700 (PDT)
Received: from mx36-out21.antispamcloud.com (mx36-out21.antispamcloud.com [209.126.121.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A053A18B6 for <dns-privacy@ietf.org>; Fri, 3 Sep 2021 21:57:17 -0700 (PDT)
Received: from [66.113.192.7] (helo=xse.mail2web.com) by mx133.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mMNju-000EZv-1w for dns-privacy@ietf.org; Sat, 04 Sep 2021 06:57:15 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4H1j7s3fLkz5xQ for <dns-privacy@ietf.org>; Fri, 3 Sep 2021 21:57:13 -0700 (PDT)
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mMNjt-0005GU-CT for dns-privacy@ietf.org; Fri, 03 Sep 2021 21:57:13 -0700
Received: (qmail 32011 invoked from network); 4 Sep 2021 04:57:10 -0000
Received: from unknown (HELO [192.168.12.74]) (Authenticated-user:_huitema@huitema.net@[50.35.13.28]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dns-privacy@ietf.org>; 4 Sep 2021 04:57:09 -0000
To: Bill Woodcock <woody@pch.net>, dns-privacy@ietf.org
References: <CABcZeBNRZsyjd-M_hKOwxdqY=Y7oZs5-d4waqPHb9gO-GJNV+Q@mail.gmail.com> <8b2ac283-614e-40d2-b6bf-5e67d5324aaa@www.fastmail.com> <9f184e77-056a-3a49-8832-249d36bbab82@cs.tcd.ie> <4cdc1d2f-47cb-9c23-f049-cf1ebf6717a5@innovationslab.net> <1a6d0690-3d03-b265-ac8d-ad5017e2aedf@innovationslab.net> <AD432442-796F-408C-89ED-CE0396B2B078@pch.net> <4237A4A2-4DF9-4746-B921-53973212834F@pch.net>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <d43f7277-377b-6f6f-1b25-2b52382492a9@huitema.net>
Date: Fri, 03 Sep 2021 21:57:10 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <4237A4A2-4DF9-4746-B921-53973212834F@pch.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.192.7
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.192.0/27
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.0/27@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5zh2yKlFwkOJL4c32G0KduLVjVx0XVkNnHJMw/amoreOWiN Jlbp35LDv6neYIU3V6MhfeXMyWnUQjjMD4JK3Wq2SxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLV8N1jesGf+4mhQUxe5Cke1HGFd932lfz+R/06O3Iy4an1KHe/ FVcvFYE7DSY4uAuvkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkgOaZXY1D 3Tei6L4lTC3Kzv6blagzf/fouhj8KehojfmLb5mum9xAXSaS3KKPtTZXWZip9+GhedmPokL8D3vh veYLhIg92+wH02ylfDiSQ0sYFBl6VX84fRovDGikEvLu7vlxwPg5iSJU22qtYbc2zIvhSJcbnX/H QqL/X9rNCJCc6iESJvKm1NV8gkr+Wu8ScVDXinOVyuIpITQ9z3M3DCinc6hm4Yij/9/ori/8mFV4 V97ui3VA1OEF+KxGdWeovz9e9Kz9hM9OSwD+bZcN+30AiIu8zMzKUMvap/FWIs/L3VJD2rnYxsyB Wmc9JBgRrnX8DAxpkCYbCO495zH8cQFVnde1UJCYLdcfX0Bx8d2hUvU7dktZ74p0dfTVB5oClJxM k6ktxQ8/GaVaQ/yY7CCifo9XLg65X5VCloHaZmhRXxKF5tPxTxfD0dMN+t5Z+cj4z3rVIuCP+WO7 SoiizjheMPxghFsjIwINNqkbXC8q7fBXfwiTkcwbv0dB5b3yNR3oW5YiBYO7UVjw0gdRPrII++x6 YSSQfv2n7TJ4De1knRDjH7QY7Fm+gQ0M40rBtaly/uPaPGs4IuAYIIDnnmIMx2SsJMcYcfaTa1Z5 siYOS4qqjKkTvrhEiORgsEtrMS+4ayUpOtEhdxekWDmK9g==
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/w7516lRMFAoNLy_v_6QF69StR4s>
Subject: Re: [dns-privacy] ADoX experiments (was: Re: Intermediate proposal (what I was saying at the mic))
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Sep 2021 04:57:24 -0000

On 8/31/2021 8:36 AM, Bill Woodcock wrote:
>> On Aug 31, 2021, at 2:23 PM, Bill Woodcock <woody@pch.net> 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