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

Bill Woodcock <woody@pch.net> Sat, 04 September 2021 09:23 UTC

Return-Path: <woody@pch.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 260E33A0839 for <dns-privacy@ietfa.amsl.com>; Sat, 4 Sep 2021 02:23:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 PiKN_7H0L9U4 for <dns-privacy@ietfa.amsl.com>; Sat, 4 Sep 2021 02:23:40 -0700 (PDT)
Received: from mail.pch.net (keriomail.pch.net [206.220.231.84]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F8B3A0837 for <dns-privacy@ietf.org>; Sat, 4 Sep 2021 02:23:40 -0700 (PDT)
X-Footer: cGNoLm5ldA==
Received: from smtpclient.apple ([69.166.14.2]) by mail.pch.net (Kerio Connect 9.2.7 patch 3) with ESMTPS (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Sat, 4 Sep 2021 02:23:36 -0700
From: Bill Woodcock <woody@pch.net>
Message-Id: <00979B3B-3603-4ACC-87B4-7E89310BA13B@pch.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_3ACFAFCC-AF01-454C-98EA-641923A6F7A4"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Sat, 04 Sep 2021 11:23:29 +0200
In-Reply-To: <d43f7277-377b-6f6f-1b25-2b52382492a9@huitema.net>
Cc: dns-privacy@ietf.org
To: Christian Huitema <huitema@huitema.net>
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> <d43f7277-377b-6f6f-1b25-2b52382492a9@huitema.net>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/Uf0wvrUVijaGaJUUql6HHSIJo3c>
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 09:23:45 -0000


> On Sep 4, 2021, at 6:57 AM, Christian Huitema <huitema@huitema.net> 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