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

Rob Sayre <> Wed, 23 October 2019 02:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 767D312006D for <>; Tue, 22 Oct 2019 19:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 HasEl5XIUnvA for <>; Tue, 22 Oct 2019 19:54:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9072E12004C for <>; Tue, 22 Oct 2019 19:54:37 -0700 (PDT)
Received: by with SMTP id i12so6957110ils.6 for <>; Tue, 22 Oct 2019 19:54:37 -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=SAaVNsljEuMV2o/Kj+vND8XrsD/3ijlHFN+G/NM3/JY=; b=ktAOZkYIGJoJFu5OR+6p7Ln4ZaaylYxyqQuGnb4dYK0RfnMx2a0xDfkVCeXvzV1Wv1 Gc2lQh94n4TcsRbH/I1axZMWnvZMbHvHq5UbFuhDCYIyfE1kbI8KPbtrwEUjJbxU/s/R Cuwpruf1lhGm+QX6uSTiot+rwI7uaLOXZBMpw+ZtNrKb3B3ONBKAEZoTEvP53654YAlm s6kU5WaEEM3ZKk6czfTObX4qlvlBDP2mUkb6KPvBBkYdXYwmIrAdwzRaH33hZ6eNYwE4 2QsU6TzTwf8mkPexC/tUQHSZSqqN8D6q99FVKwktvVukV+ZY/JSorsqabpEs/8sM0qol C4Tg==
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=SAaVNsljEuMV2o/Kj+vND8XrsD/3ijlHFN+G/NM3/JY=; b=pdKJydnlEFy+1y01V8/LO+1WMKw02kb5+qa59M3s4lX2F9zEoFwEGUNDiDpIIwXrNS bpQkrC3h+7RT7NPNdytPGnNz1uGUHHbUHHpWKc1+qeV9D17htoPr5VCbpKBNeFVFtcpA IkoAwoFSkAF4tFzkJ5ife77BK4vNTIN0m/GIT/v5CfcQMcA1CEMH7MO0pYpIgaH6//Di /z8pRz4P2PLcbZHOHNYjq0y+ZHTUqatxpjO07jqGA/kA0KE+e4pLD3oTPI4/gwP43ZDX /x4js8WXuptrlAy9zGhFmAcn4TaLoGu07WldSgd5fB34Yunz1/tvlhmlrAP1CGyx/ZtS 6LYQ==
X-Gm-Message-State: APjAAAWqUsuUyBK3KoM/K6vw5Vp4qrpo/Ugi92tSbEOjFCv+wMQfnc7F KwD69Vlm2zbUoF7yKMbKOkX8v6LBoZdOVPea/2s=
X-Google-Smtp-Source: APXvYqx873ue1kiViaDtzTiWDco9i9CSRKbtwIDQlHIBKXb54RJUMTxG3wBL8P7x/RgciL8UqCu/8R5G1J0apBP+qJ0=
X-Received: by 2002:a92:db0c:: with SMTP id b12mr8053294iln.49.1571799276625; Tue, 22 Oct 2019 19:54:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Rob Sayre <>
Date: Tue, 22 Oct 2019 19:54:25 -0700
Message-ID: <>
To: "Salz, Rich" <>
Cc: Stephen Farrell <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000008aa3cb05958b09d9"
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 02:54:39 -0000

On Tue, Oct 22, 2019 at 7:29 PM Salz, Rich <> wrote:

>    - Low numbers might encounter all sorts of well-known cryptographic
>    problems, and varying the padding of the domain name with any granularity
>    would tend to narrow the search space for an attacker.
> What well-known cryptographic problems?  Varying the padding can also *
> *add** security because could show up with two
> different sizes.

Hi Rich,

To be clear, I am in favor of varying padding. I want the "zeros" field to
have a prefix and I want my client to do whatever it wants with that
buffer, within the boundaries of an unsigned 16 bit integer.

I was concerned about a couple of different issues. The first is that the
search space for the plain text is actually quite restricted. For example, "" might only vary by three characters vs other ""
domains. So, 16-character padding boundaries might be an issue.

The other is that I worried that an attacker could use brute force to
replicate traffic, and thus determine what was requested. I couldn't come
up with a way to do this easily, but I did worry that a small search space
in the SNI text would make it easier.

And, as I wrote, I am not an expert in these matters. From what I do know,
I think padding the buffer to the maximum likely size seems like a good