Re: [TLS] draft-ietf-tls-esni feedback

Ben Schwartz <> Tue, 22 October 2019 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A3EE1200B3 for <>; Tue, 22 Oct 2019 07:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 rGlbUtEQyezm for <>; Tue, 22 Oct 2019 07:56:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15BE61200E7 for <>; Tue, 22 Oct 2019 07:56:19 -0700 (PDT)
Received: by with SMTP id q1so20816591ion.1 for <>; Tue, 22 Oct 2019 07:56:19 -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=YsBylWTRq8ycAHoCVPX4WCP1MpaknC2PRi7JglLw3Uw=; b=gcU9Abu/PMljcPfdpewnRpvCgzPP5c9JTUP+jtUAggWpqbUIpREofeWQ7+f0zu1etP SMwdmhDPXm3rub0y3dJt4a7o5wm2pCE+rD/Hx+U77OWveD4z0ydfQQTHDCJc5mWmvPQL Y87KQhsYLsfDP9BQcqtJwLylOUNjj4Q9+scFfyEheVtA6XnEhn2Xf5b9QlPRB3ObVTwz rSoh2mT+EF/C8tMtVM8ta1wIVV6S/vtWP6z3D4MsKKE3IoDQ+AdKTABdgNy3nYZ/WSMJ Cncfc8Y5OmA8dsHg76a3Jy0zhlLYFrKQlD9+/5I4LlFRaQqVkrAt9EaMzVbKRL+jIVzB +CXw==
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=YsBylWTRq8ycAHoCVPX4WCP1MpaknC2PRi7JglLw3Uw=; b=qKaH/xi6FyFOImOBQkQN7LvghaYMFzKFT0U701qn5ZmT3as25mdRffnhIQ2ChpWZGr f/Ovw8evIHbMx6sdSP5BYxl5kVgIKU/cbgf5LBhFFToN9HvzvjJKh5/jyAlmIE4vYzZf SHyz/4cn1uEc1mnWo/ZiriRyjH9/RY6yurvItluPZrrxjOMMV/PMQ5QbG8V3bUfItin6 mzcCBiHz8jtBGYWtPOcLIdwCDYSFYsiur3IdYUBWOdghw6YRC1wSWAjyM4eyf4Vyz0Yn 7ZkqNS4Yf6gBDwSnUIAHrFpZjkuxkpJ7C+Tkd5A/8aMlTA1g60JHH7k7DkAO6OzK1F5n nCGg==
X-Gm-Message-State: APjAAAVee6SX1IuIp+QGsG2aAn8g/EXC+6zFAeGUrL/jxkoIDdLvt+Wg kwW/oHPvM9ppz4XvtSs44CGud1w/01+ccNheMyi/IQ==
X-Google-Smtp-Source: APXvYqy57voubQ9jeDDEPcfJr0AxP4llV0EShaI78oM3lLZt5rCG3itq3ASjGrMeCE/abVDEnkE1m7L8B5mj1iRuI8E=
X-Received: by 2002:a05:6602:1c4:: with SMTP id w4mr3939981iot.153.1571756177900; Tue, 22 Oct 2019 07:56:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 22 Oct 2019 10:56:05 -0400
Message-ID: <>
To: Stephen Farrell <>
Cc: Rob Sayre <>, "" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000b16486059581007b"
Archived-At: <>
Subject: Re: [TLS] draft-ietf-tls-esni feedback
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: Tue, 22 Oct 2019 14:56:21 -0000

On Tue, Oct 22, 2019 at 4:21 AM Stephen Farrell
<> wrote:
> Hiya,
> On 22/10/2019 04:27, Ben Schwartz wrote:
> > Note that the current text in the editors' draft says that when
> > applying GREASE, "The padded_length value SHOULD be 260 or a multiple
> > of 16 less than 260.".  We don't need GREASE to send 260 all the time,
> > and the draft doesn't recommend it.
> ISTM that GREASE needs to follow the kinds of lengths
> used in practice to be most useful, so if 260 does get
> widely used, then I guess that's what'd be most useful
> to GREASE.

Agreed.  (Although the details of this are potentially tricky, like
whether the random length can be sticky without accidentally labeling
the user.)

> > Personally, I expect that 260 will be rare for real deployments,
> > because most systems serve a fixed, known set of domains, and those
> > that serve a large, dynamic set probably already impose a tighter
> > length limit.
> I don't know of any hoster or service with such a name
> length limit. Do you have any example where a DNS name
> that can be published and used as a TLS SNI would be
> declined by a service provider?

Sure.  For example, tumblr limits usernames to 32 characters:

These usernames also form the subdomain part of the *
wildcard, so the longest allowed name is [32 chars]

I expect that most wildcard TLS hosts impose similar limits.

> > One intriguing alternative would be to define some ESNI ciphersuites
> > that encrypt a strong hash of the name.  Then a server with a large
> > but finite name database can choose one of these ciphersuites,
> > pre-compute hashes for names when entering them into the DB, and
> > quickly invert incoming hashes with a DB lookup.  I wouldn't want to
> > make this the only option because it can't support true wildcard
> > servers, but I think it would cover most potential users while
> > limiting the length to 32 octets or similar.
> Yeah, that'd be nice but as you say doesn't work well
> for wildcard certs, which I think is a showstopper.

I don't think it's quite that bad.  For example, this approach would
work fine for tumblr in principle.  Any hash corresponding to a name
that exists can be inverted from their database.  Any hash
corresponding to a name that doesn't exist will return the default
cert, which still covers *

The case where this doesn't work is when multiple wildcard domains
share an IP but not a certificate.  That seems most likely in a CDN
context, where multiple wildcard customers could be sharing an IP and
providing their own certificates.  If the CDN's operational
architecture allows pushing all wildcard customers into a single
certificate, the limiting factor becomes the number of names allowed
in one certificate.

> I
> do think there are other algorithmic options we could
> go with though, that would work.

I suppose a server could indicate that the first N labels be included
verbatim, and the remainder should be hashed.  Or maybe it should only
be hashed if it's longer than the hash size ... there are all sorts of
options here.

> Cheers,
> S.