Re: [TLS] HTTPSSVC record draft - ESNI alternative for HTTPS

Erik Nygren <> Mon, 08 July 2019 22:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2EA4C120094 for <>; Mon, 8 Jul 2019 15:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.106
X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.247, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S9xBJPPfoZ5U for <>; Mon, 8 Jul 2019 15:09:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C587120077 for <>; Mon, 8 Jul 2019 15:09:03 -0700 (PDT)
Received: by with SMTP id x4so18762816wrt.6 for <>; Mon, 08 Jul 2019 15:09:03 -0700 (PDT)
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=JLhTTMGnG/l9jcqBtKRtBL94jkLrC/UmoUEZlJXfqSA=; b=oWKfr4N6vsr8ac+ay8OrUoZLq48ktNzQaSo/3iiwZGrdoQBe2jjzWnaPGxVWa679Dz h3GZFEvB+ZbvFsq9R4U3Ou1wV1EzTDSdZNKBk9JZuID6Xd6qSLNuNqE7o70pXXE4ndJk EAHqdFGsLjR+05jVM0bHK38qfcA2LKHssy0VKKFQF8c/6+/jQas1quJxRmOxozNKAnUN DgQy6vMJTUS5CitHNFUYzzSviXbSHE8cnm0MrqsmxYP/uqLg2NqrBy5uiLi9DkCIcapv dFS8QrSSMAzW4d2y/VnpcOryDyG8w1T+/f0eXpYFEtiVSLARChxnvDfVZ8pBxFuc1D2I PV8w==
X-Gm-Message-State: APjAAAXzxvaEJNJgUWXut0d+HPtmtMuLJqMr/WGObZvevUni4W1x0SE8 5Cs6Oei/z5RHCNsL9/WbcCXMUPpMIgcuGQ3Hhzw=
X-Google-Smtp-Source: APXvYqy7bsxLDiqxSCT6UYxP+oMBEvkyrK+TL/404L2cX1fTrdG0UMDQi80VTDcl0XQSHvSIp2UCXDjandmB2M5Lc7w=
X-Received: by 2002:a5d:43c9:: with SMTP id v9mr20350223wrr.70.1562623741388; Mon, 08 Jul 2019 15:09:01 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Erik Nygren <>
Date: Mon, 8 Jul 2019 18:08:50 -0400
Message-ID: <>
To: Stephen Farrell <>
Cc:, Ben Schwartz <>, Mike Bishop <>
Content-Type: multipart/alternative; boundary="00000000000005ed1b058d32b1bd"
Archived-At: <>
Subject: Re: [TLS] HTTPSSVC record draft - ESNI alternative for HTTPS
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Jul 2019 22:09:05 -0000

Hi Stephen,

On Mon, Jul 8, 2019 at 5:39 PM Stephen Farrell <>

> On 08/07/2019 22:27, Erik Nygren wrote:
> >
> > In particular for the TLS WG, we'd be interested in hearing if this would
> > solve enough of the ESNI-key-delivery-via-DNS needs for the HTTPS
> use-case.
> I'm not clear if you envisage this entirely replacing the
> new ESNI RR (as defined in ESNI draft-03), or if you envisage
> both being defined, with this one (HTTPSSVC) being used for
> the web and the ESNI RR for non-web uses of TLS, or maybe
> something else?
> It'd seem like a bad plan two have multiple ways of doing
> the same thing, but I guess there're trade-offs in various
> directions here.

My thinking is that different protocols have different needs
and requirements for key delivery via DNS.  As such, separating
out the ESNI key format from the DNS record for provisioning
makes sense.  EKR had the valid point that it would be valuable
to have a basic way of doing ESNI key provisioning for protocols
lacking complex requirements.

This could end up as "protocols should specify bindings for how
ESNI keys are delivered via DNS", with a HTTPSSVC RR for the HTTPS
use-case, perhaps with other protocol bindings for other things with
specific requirements, and with an ESNI RR (which might be able
to be made simpler if some of the Web requirements can be abstracted)
for generic use-cases.

A downside is that this does add complexity for tools that operate entirely
at the TLS layer such as openssl s_client that would be happier if only
an ESNI record existed.  However, the HTTPS use-case
already has a bunch of other scenarios such as HTTP/3 that break/blur
this abstraction layer such that it may be that this type of HTTPS
management and DNS resolution needs to be done at the HTTP session layer
regardless, with TLS libraries providing an interface to pass in ESNI keys.

Encrypting authoritative DNS from recursives to authorities is in
its early days, but it would not surprise me if similar requirements
show up there and require a new DNS record type.  (eg, an extensible
NS record or an extensible record named by an NS record that includes
information about protocols and ESNI keys and the like.)

Best, Erik