Re: [dns-privacy] Possible use case: Opportunistic encryption for recursive to authoritative

Paul Wouters <> Sat, 08 August 2020 04:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3626E3A0CA9 for <>; Fri, 7 Aug 2020 21:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2gWnLp9USsQG for <>; Fri, 7 Aug 2020 21:18:29 -0700 (PDT)
Received: from ( [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 014113A0C9E for <>; Fri, 7 Aug 2020 21:18:28 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4BNpr21slTzCm; Sat, 8 Aug 2020 06:18:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1596860306; bh=rB37b+rYPxjDJl9qi3M8ZaLIsSOwJEOXdTltsMaHqp8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=T80+r8KiUpQJwUEjBWgvyiVBhroWmlOwXtotttnMlrZfYo1gy4GPDMa6Z0kVxZaR8 OKbx1/XvQy2MAu/TiHz1gRYza96UZre5BiWN7GzVMkryiLxB3YbrfjiXNTHiydstie I2m7cVW/3H/oMbofxvVx5qHCqKwtWx0LRF+NkmnU=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 84-RmYEhkPS1; Sat, 8 Aug 2020 06:18:24 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Sat, 8 Aug 2020 06:18:24 +0200 (CEST)
Received: by (Postfix, from userid 1000) id 361116029A37; Thu, 6 Aug 2020 23:04:39 -0400 (EDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DA0E82C94; Thu, 6 Aug 2020 23:04:39 -0400 (EDT)
Date: Thu, 06 Aug 2020 23:04:39 -0400
From: Paul Wouters <>
To: Ben Schwartz <>
cc: Paul Hoffman <>, "" <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [dns-privacy] Possible use case: Opportunistic encryption for recursive to authoritative
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 08 Aug 2020 04:18:31 -0000

On Thu, 6 Aug 2020, Ben Schwartz wrote:

> I think opportunistic or unauthenticated encryption is worth pursuing. 

In general, yes. but ...

> On Thu, Aug 6, 2020 at 10:59 AM Paul Hoffman <> wrote:
>       Use case: Opportunistic encryption for recursive to
>       authoritative
>       In this use case, a resolver operator says “I’m happy to use
>       encryption with the authoritative servers if it doesn’t slow
>       down getting answers by much”, and an authoritative server says
>       “I’m happy to use encryption with the recursive resolvers if it
>       doesn’t cost me much”.
>       Opportunistic encryption is defined in RFC 7535.

Poorly and confusingly and not as how people have used the term in the
past. So that document has just ruined the term. [I was asked to
co-author and refused]

The "opportunistic" part really means, "we will try encryption, but if
for whatever reason it does not work, we will fallback to
unauthenticated or even cleartext".

That is different from "Hmm, I'm busy, I'll just do cleartext for now".

Email is good example of where TLS is used alot with bogus certs, and
thus basically doing unauthenticated encryption. It's useful as it helps
against passive attacks.

In this case though, for auth servers, I see no reason to do
unauthenticated encryption. There are usually two reasons for
unauthenticated encryption. The first is that the party wants to
remain anonymous (eg most HTTPS clients). The second is that it is
too hard for entities to get a veriable ID in a trustworth PKI.

In the case of encrypted DNS to authoritative servers, those servers
obviously can have an cryptographic ID based on FQDN. And
"opportunistic" then really means "you should do it and hardfail if
there is an issue".

>       The assumptions behind the use case are:
>       • More encryption is good for the Internet


>       • Resolver vendors are smart and motivated

Some are, and a lot are not.

>       • Most resolvers don’t validate with DNSSEC and may never want
>       to

This is not true anymore. And even if it were, we should encourage those
to upgrade. At the IETF, we have done a REALLY bad job at keeping secure
DNS as an optional feature. The more we treat it that way, the more
others will treat it that way. We should really do the opposite. DNS
without DNSSEC is legacy. It's irresponsible. It's vulnerable. It's
being actively abused. Upgrade your DNS.

Then, you automatically get to AUTH servers having a DNSSEC based PKI.
You can give them a public key record type like TLSA, and do encryption.
You allow plaintext, and in 10-20 years we turn off plaintext.

>       • Authoritative operators don’t care much about encryption

I don't think that is true either. If they could install an ACME like
client and get fully automated optional encryption, I bet most would
just turn it on.

>       • Other use cases for authentication stronger than opportunistic
>       may appear and would co-exist with this one

Opportunistic for _this case_ is just too weak. We have a PKI system
with DNSSEC that is core to these DNS servers already. We basically
get the PKI for free, so just do it authenticated.

Another item that keeps coming up is people fearing an extra RTT on a
DNS connection to an AUTH servers to pull the public key. DNS already
has caching and for DNS encryption to yield anonimity, it has to be done
with nameservers hosting thousands or millions of zones anyway. Or else
encryption doesn't buy you anything. You can take that 1 RTT for or to get encryption for a few
thousand domains. No need back DS hacking of public keys.

>       The other slides had thoughts about possible solutions that
>       implement this use case, but before we go there, I wanted to
>       find out if more than a handful of people here are interested in
>       this use case. If so, I could turn the above into a draft with
>       some possible solutions for us to bang on.

We should work on adding encryption and moving towards an encryption
only solution. Not wishy-washy opportunistic with fallbacks. Not for