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

Ilari Liusvaara <> Wed, 23 October 2019 17:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 473D9120B84 for <>; Wed, 23 Oct 2019 10:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ycYgdYcqCkAj for <>; Wed, 23 Oct 2019 10:11:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 881D7120B7C for <>; Wed, 23 Oct 2019 10:11:20 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8EDAECA2C; Wed, 23 Oct 2019 20:11:17 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id ToY4OQHZItQR; Wed, 23 Oct 2019 20:11:17 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9C33272; Wed, 23 Oct 2019 20:11:13 +0300 (EEST)
Date: Wed, 23 Oct 2019 20:11:13 +0300
From: Ilari Liusvaara <>
To: Ben Schwartz <>
Cc: Watson Ladd <>, TLS List <>
Message-ID: <20191023171113.GA472177@LK-Perkele-VII>
References: <> <r480Ps-10146i-D05F1D3FC7BC4B899AE60F28D44FDF74@Williams-MacBook-Pro.local> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
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: Wed, 23 Oct 2019 17:11:23 -0000

On Wed, Oct 23, 2019 at 12:13:39PM -0400, Ben Schwartz wrote:
> On the topic of radical suggestions, here's another one:
> In brief, this replaces the variable-length name with a fixed-length
> hash, plus some accommodations to allow *,
> *.*, etc.
> My hope is that this design would work in the architecture described
> by Watson, while saving ~220 bytes in each ClientHello.
> One interesting feature of this design is that it doesn't require each
> wildcard domain to publish any unique DNS record.  Instead, all
> third-level wildcard customers can share a configuration, all
> fourth-level wildcard customers can share a configuration, etc.  This
> distinction is not visible in the TLS handshake, so the anonymity set
> is not reduced.

AFAIK, PKIX in practice only allows single full-label wildcard in
terminal position (the only place * can appear is as first character,
followed by label separator).

And the scheme in #186 does not seem to distinguish between
"" (the base name) and "*" (a wildcard).
There also seems to be issue that seemingly nothing constrains the case
of hashed encoding. And you do not want to deal with arbitrary casings,
as the number of those quickly blows up.

Perhaps a simpler way would be to have a flag that causes the first
label to be overwritten with '*'. That would be set on nodes covered
by a wildcard certificate. Alphabet would be hashed lowercased. Then
the server could just hash every lowercased name from every known
certificate and use the hashes as lookup table keys without worrying
about encoding. And in the structure, the label_limit, num_labels and
length field for name_digest seem to be superfluous.

This would give that the encrypted_sni is 64 octets with AES-128 or
Chacha20, and 80 octets with AES-256.

On optimizing stuff, the length fields for record_digest and
encrypted_sni in client structure are also superfluous, because the
length of record_digest is impiled by suite (and unknown suites are
unprocessable anyway) and encrypted_sni runs to end of explicit-length
record. The length of key share probably can not be removed, as some
algorithms may have variable-length ciphertexts.

Using the above figures, this would mean that the part after the
share would be 96 octets for AES-128 and Chacha20 and 128 octets for