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

Eric Rescorla <> Sat, 12 September 2020 22:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C31753A0E67 for <>; Sat, 12 Sep 2020 15:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4gdzS5f5Htmj for <>; Sat, 12 Sep 2020 15:43:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95C253A0E64 for <>; Sat, 12 Sep 2020 15:43:09 -0700 (PDT)
Received: by with SMTP id v23so15518550ljd.1 for <>; Sat, 12 Sep 2020 15:43:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nLdRmhTFYo1q/KUk2rq8Rvk23i6DX7Pe6BBMXcRntpk=; b=Jv0vMjGH6DViz2v/WufFyax7wDIs6bTlZVnCH1D+j2qt64FUmyfhi2809aWJPuhByS 391APSRIE7+kcw3PE3LBk9y983IHaxT8Xxmk707id/qRA5fl7zjTSFxhtvcDqhk+Of01 ayeItim7U6l1SiHJ5H8t6uHHTr58gOE9WOIdl1WhJoAUDKvbHXJ4UhWxBkzE3FoyI5rx /E2XwmyLBxl0IjvBRKnJY7uPyNiENpUmqOo9YGebBfVWZaw2zJfNyONLDlGSh6tqtRR4 lXm+vPs/X1Qesm4Zoa0tW7lxYFkvemlnjs0TKxk873YkGs1cu9kswbN6RHrdQuXLbW20 EFKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nLdRmhTFYo1q/KUk2rq8Rvk23i6DX7Pe6BBMXcRntpk=; b=gQ2mGPX+LMNlIIfRyWHp9NNxY6LHZNInfqGLr51awbmtlMVXqoUpLAuEQf2mYBmK8y xicQRemegSYbExlU4SykpZpSP/7qWs3MZQ1uEh5OQejis/5EvQLe8FMnX0I3IyS2agmG woBAIgrOobXpc/b8j7HeaW3dTcYQ0oF8eda3Wmp22F+3UqoulOiPktm8e5glv8wq6TwQ SH35styQO9neD7CPZN017BXLXyyEHAnnK+n4eV4fQzJUJX4sHNjGWnl1fdSoqGB0XJ8w bzi6L1TLzkoctrqYo7p7qRvH0qBskEBnwZk/D+81k5mAgv/k8EpKcl5IVlokq7Pf+/PB ASlQ==
X-Gm-Message-State: AOAM5324tWJV/JZjUimQd+cIBCle08g6986JMebnaHLQGMZUPUxnf4z+ YHBEkIJS3mTgwSIVEHvRWECkRRaSDLzsQi7UfGs8+g==
X-Google-Smtp-Source: ABdhPJwpnrqVMrVYLwFkXcLW1SchHZo95+epRqJadxA8VxVm23ZnBg796CjIhgpmI3c8fEoKPcV9uGyD67TMEyurWuo=
X-Received: by 2002:a2e:7819:: with SMTP id t25mr2696606ljc.371.1599950587744; Sat, 12 Sep 2020 15:43:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Sat, 12 Sep 2020 15:42:31 -0700
Message-ID: <>
To: Paul Hoffman <>
Cc: James <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000070eb2805af25865a"
Archived-At: <>
Subject: Re: [dns-privacy] [Ext] Fwd: Opportunistic encryption between recursive and authoritative servers
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, 12 Sep 2020 22:43:12 -0000

I think I largely agree with Paul Wouters here.

>From my perspective, in order to enable non-opportunistic
recursive-to-authoritative DNS we need two things:

1. A way to indicate that the server ought to have TLS.
2. A way to authenticate the server when you get there.

As Paul says (2) is a solved problem, either via WebPKI or TLSA

(2) seems slightly more difficult, and I defer to DNS experts, but
I've seen a number of proposals here ranging from the principled to
the unprincipled (naming the server, so I
imagine the problem is soluble.

If you use TLSA records, you obviously need DNSSEC validation, but
that doesn't seem like that big a deal if you're already running a DNS

If you use WebPKI, DNSSEC *does* help here in that it prevents whoever
served you the NS records for the authoritative from lying to you, but
it's not essential. For instance, if you do TLS to the authoritative
for .com and it refers you to, then an
on-path attacker cannot force you to not speak TLS, so this is a strict

I don't deny that opportunistic TLS is of *some* benefit, but given
that non-opportunist is much stronger and doesn't seem much harder,
I don't think we should proceed with it. I especially do not think
that we should proceed with a version where both discovery of TLS
support *and* authenticating the server are optional. If we somehow
find that TLS discovery is difficult, then the right thing to do
is something HSTS-like, where the server has to have a valid cert
(or TLSA) but the client may discover that TLS is required through
an insecure path.


On Sat, Sep 12, 2020 at 9:34 AM Paul Hoffman <> wrote:

> On Sep 12, 2020, at 6:19 AM, James <> wrote:
> >
> > 1. The absence of protocol agility bothers me - whilst I do not think
> the use case described in this document lends to DoH in particular being
> suitable, DoQUIC and not-yet-existent protocols could also be applicable.
> There is nothing in the current proposal that specifies the protocol that
> the two sides use. Additional protocol discovery methods can be added; we
> just didn't have any other desired protocols at this time.
> > Is there any reason besides simplicity you didn't consider using the
> ALPN as identifier?
> Simplicity counts. :-) However, if you want to use an ALPN method, this
> document certainly does nothing to prevent that.
> > 2. I disagree on the points around authentication and section 2 could be
> updated to better encourage adopters to implement matching TLSA records for
> the certificate they present during the TLS handshake - with a clear
> statement that recursives are not required to query this record type before
> TLS negotiation, nor explicitly fail if it mismatches.
> There is no value in opportunistic encryption to use DANE or any other way
> of authenticating the TLS server. Paul Wouters has said that he does not
> support encrypting more DNS traffic using opportunistic encryption, but so
> far has not written up his use case for regular (authenticated) encryption
> where some DNS lookups would be blocked due to inability to authenticate.
> Maybe you could write up such a use case and send it to this WG so they can
> compare use cases?
> --Paul Hoffman_______________________________________________
> dns-privacy mailing list