Re: [dns-privacy] Opportunistic encryption between recursive and authoritative servers

Paul Wouters <paul@nohats.ca> Sat, 12 September 2020 00:03 UTC

Return-Path: <paul@nohats.ca>
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 D94673A005E for <dns-privacy@ietfa.amsl.com>; Fri, 11 Sep 2020 17:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.078
X-Spam-Level:
X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NO_DNS_FOR_FROM=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 njIB6YzJLElQ for <dns-privacy@ietfa.amsl.com>; Fri, 11 Sep 2020 17:03:05 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 592C53A005C for <dprive@ietf.org>; Fri, 11 Sep 2020 17:03:05 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BpCWC36sfzF3y; Sat, 12 Sep 2020 02:03:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1599868983; bh=DKXZQGG/6x5tfkdWKvUWG7RIUBmyh0Xd5aizKKcFnjI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=n2xlyRHdbwbW9l405mAl1If/p3mLbfczQ9ahBSpnX6bHncv4puq9F6gyXFGtu3sTU 9PixuMJ26y7moF+hhskZ6GSymFvF7iwDZC1dpQammf0EatS7tANRuI5DC+Pj9t3rMj 4/E2mj24cocmw+lYhM0P2IxDlkvu/wF2mLXXZRGg=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id x3ur7woOV4s2; Sat, 12 Sep 2020 02:03:01 +0200 (CEST)
Received: from bofh.nohats.ca (unknown [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 12 Sep 2020 02:03:01 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 35FEC6029BA6; Fri, 11 Sep 2020 20:03:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2DB3D66A7B; Fri, 11 Sep 2020 20:03:00 -0400 (EDT)
Date: Fri, 11 Sep 2020 20:03:00 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Paul Hoffman <paul.hoffman@icann.org>
cc: "dprive@ietf.org" <dprive@ietf.org>
In-Reply-To: <BBA7E731-34C9-47C8-B584-7781DD7F4A59@icann.org>
Message-ID: <alpine.LRH.2.23.451.2009111952110.1078938@bofh.nohats.ca>
References: <BBA7E731-34C9-47C8-B584-7781DD7F4A59@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ReTMwvCCp0suj1JjprZ3mHQtlJg>
Subject: Re: [dns-privacy] Opportunistic encryption between recursive and authoritative servers
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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, 12 Sep 2020 00:03:07 -0000

On Fri, 11 Sep 2020, Paul Hoffman wrote:

> Greetings. The discussion of encrypting the recursive to authoritative traffic keeps getting bogged down due to lack of use cases. Puneet and I would like to propose a specific use case (the desire to encrypt much more traffic, even if there could be an active attacker in the middle). With that in mind, we wrote up <https://tools.ietf.org/html/draft-pp-recursive-authoritative-opportunistic>. The abstract says:
>  This document describes a method for a DNS recursive resolver to use
>  opportunistic encryption when communicating with authoritative
>  servers.  The method here is optional for both the recursive resolver
>  and the authoritative server.  A motivating use case for this method
>  is that more encryption on the Internet is better, and opportunistic
>  encryption is better than no encryption at all.  Nothing in this
>  method prevents use cases that require better encryption.
>
> We would like DPRIVE to adopt this, and we are open to suggestions on how to improve the protocol.

And as I've told you before, your use case of "opportunistic encryption"
makes no sense here. The DNS allows for publication of public keys without
any further infrastructure. You need your TLS certificate for encryption
anyway. Why not just stuff that public key into DNS via a TLSA record?

This is not rocket science. We already do TLSA for email at large scale
now. To do it for DNS is the same except it's even simpler because the
protocol we are protecting is the protocol used for authentication of
the encryption.

As the document already indicates, there is NO difference in setup for
the authoritative server. It needs a TLS certificate. It can use humans
of shell scripts to set this up once using self-signed certificates,
or it can just run an ACME client to automate this.  That is, it is
easier to get a public valid TLS certificate for your DNS server, than
it is to install a self-signed one.

On the client, it is doing TLS authentication as part of the protocol
anyway, and just "throwing away the results". So nothing is saved there
from code complexity other than not looking if the CA cert used is in
its local (system) store of trusted certificates.

Opportunistic encryption to authoritative servers is just too silly.

I am strongly opposed to doing this work.

Paul