Re: [TLS] DNS-based Encrypted SNI

Ben Schwartz <> Tue, 03 July 2018 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 360F7130E50 for <>; Tue, 3 Jul 2018 08:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 SyLTudw21Ixj for <>; Tue, 3 Jul 2018 08:21:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 05DFC130E6D for <>; Tue, 3 Jul 2018 08:20:36 -0700 (PDT)
Received: by with SMTP id t135-v6so2057538iof.7 for <>; Tue, 03 Jul 2018 08:20:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OCwaTDHW3hQDiNCcGNiml7/pZQi2jvxfVZRUb9RB8A8=; b=XibhJCIANy49GcvLNpLs5jY5RzD2kktN6JkoE4v6gCJT0cir+4XWUoo+S4TveYozlX QE4H0Iqkuvx6jtqet+A9a1/e4PWRmBCK/5wZY2FZqOrU1ViSKsKXe06R9VM6mp9548HE ycpvm5Y2bqYdaWoQMDqSa/a90UC7Er6DibgPig5tJVSwnsIaFQzKgqiK/wv0rHC/X97c mAKb+eoVexD9wgda1Iarw0N5qviedD7zvXJwk6Iz7Glnef4oUhwVpFuHnuFEaE7OzOP9 5L03hC3+ywCcdOgJMEmlf6/WZ7vwzfGYBb9kGeor22l4Bhwwkj7V+/dbhU/8AZQ6Nqp8 jRoA==
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=OCwaTDHW3hQDiNCcGNiml7/pZQi2jvxfVZRUb9RB8A8=; b=XrGqp48uhowDMC2hQL3tr9ftmRSqMT9tK8wpbj820uPt7npBxzBDkxEWUp3XUXJcsd n7j6IoX6LTtcPQX28zx11ytjeA2shYE94wdvVYZdjgJikSvdlJgt8EOPubEOZTqADctP 8w/6FJjjU+dXftBrGHQyoSFvARwSEuwQN+2ptlpxlIZiCoMDyuXJWwkCAUZK70Jgftbr RCRIG6KBOrCOqjZgniRlEX/F67T4LQfOat7dQZwsuDkG1zQeO/cj3cVD1SMhwggLN6sr EAXCklh7r8SNQ8e7R10kRIRYLnpNjMAgL11ooT4TKNuIObgjIY/FHjUm736cBZibSOHM RqCQ==
X-Gm-Message-State: APt69E1583kE8xPU1CPjHsjsLRYTD5wPV9z2Ekopw5RUOCT44qTI+XnV pQysR2MO4IoHswXvVs8VVWrUCZQU1TNTpsZF0W8f2Q==
X-Google-Smtp-Source: AAOMgpeq6eJgLLFBZ42NaxJPZ8ewCV/zVE2tceIGk1ml9T7+oDBfuVHThWcGOU50BOiXPYclL+T4XWQCHVu9JMNm4So=
X-Received: by 2002:a6b:f812:: with SMTP id o18-v6mr23636860ioh.235.1530631234713; Tue, 03 Jul 2018 08:20:34 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 03 Jul 2018 11:20:22 -0400
Message-ID: <>
To: Eric Rescorla <>
Cc: "<>" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000129580057019dbb5"
Archived-At: <>
Subject: Re: [TLS] DNS-based Encrypted SNI
X-Mailman-Version: 2.1.26
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: Tue, 03 Jul 2018 15:21:11 -0000

On Mon, Jul 2, 2018 at 7:41 PM Eric Rescorla <> wrote:

> Hi folks,
> I just submitted:
> This draft describes a DNS-based approach to doing encrypted SNI.

Thanks for this proposal, Eric.  I fully support this line of work.

This proposal obviously bears some relevance to the SNI Alt-Svc + DNS
ALTSVC drafts in HTTPBIS [1][2].  That's OK; we'll sort it out eventually.
I hope people interested in this draft will also check out those.  In my
view, ESNI and those drafts are two complementary approaches to this
problem.  I can see reasons to pick one, or both, or a combination.


On Mon, Jul 2, 2018 at 11:59 PM Eric Rescorla <> wrote:

> On Mon, Jul 2, 2018 at 8:53 PM, Paul Wouters <> wrote:

> It is strongly recommended not to use TXT records. Why not use a new
>> RRTYPE? Everything these days knows how to serve unknown record types
>> (see RFC 3597). The only possibly exception is provisioning tools of
>> small players, but this document starts of saying you basically need
>> to be on a bulk hosting provider anyway. They can properly provision.
> See:
> <>

That logic (CNAME compatibility) requires not placing this information at
the apex, i.e. using a prefix, as you've done.  It doesn't preclude using a
new record type.  The DNS ALTSVC draft, for example, does both.

Some other thoughts:

I expect much nitpicking of the exact DNS syntax.  You may end up wanting
to describe that separately, especially since these "introduction tokens"
may well be useful to acquire over non-DNS channels (e.g. Alt-Svc) and may
be useful for non-SNI purposes (like 0-RTT, as you've noted).

I wonder how well this scales to a "large key" future (e.g. post-quantum).

As described, this approach seems hard to use with a domain load-balanced
across two CDNs.  (I don't know how important that use case is.)

One concern I've heard many times is that we can't add non-A/AAAA queries
to a browser's critical path because there are middleboxes and buggy
recursives that will just drop them, leading to a DNS timeout delay on
every new socket.  However, for encrypted SNI I think we can ignore this by
focusing on clients with DPRIVE or DOH enabled, which should avoid these
kinds of problems.