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

Watson Ladd <> Wed, 23 October 2019 05:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2959C120058 for <>; Tue, 22 Oct 2019 22:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, 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 mAPL_j8csnDz for <>; Tue, 22 Oct 2019 22:39:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 51868120024 for <>; Tue, 22 Oct 2019 22:39:38 -0700 (PDT)
Received: by with SMTP id y127so14987653lfc.0 for <>; Tue, 22 Oct 2019 22:39:38 -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:content-transfer-encoding; bh=HsaHsPE4HuxpzXRNqadzslzXFI44CBQHe0ZWKMFld1A=; b=ZwId5pzskfHPNcCrcCNjFqpb0dHZdp3raOIUeXSEn5COKUN4sn5ckE84zRMTYoVJbF IdUMgca/kqYgkX37Rd9QoPxhemBLDxqHuv3/vM1UGjQsKK/ZlYIeBJu1lRgS3SsZU2Pm ahAIrvU4vzf6hOrawyml0/Qt/JsEDNkJJAKj5k9ye6NhCQBTUfVGTuma++W4CNhoM0If q3mOCf1liru+I+b04rcliSNS2WyYhB3c21bOxO0lFu9Q5eRI4G+Fc2k2Dcew4Aol6upo if3YQKqre0fi7XYxP46ug985IZtknW2yRtiJIQULO90iJOb9Ig0it1LeTxG4DtPRjViR USfw==
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:content-transfer-encoding; bh=HsaHsPE4HuxpzXRNqadzslzXFI44CBQHe0ZWKMFld1A=; b=nm735/UYOH2Nk9Uqn0+D2VtjQUpr58PfMEUeObvE2lRmZ0V/tWruTjcFQYbYDb1DG1 SrEJn0+P+QnUfbuIpPv5w8sTIcl7gKLUI0bJZHPaL5zpSodldXQuMuDA1ny/u+heoow9 wdeiQPPHBUMhixbK0DTooxNlRECDrbvG+BINMxrdFbHoqLwAzWolqWNv+yiFDIFP2UW7 vd2GM3D2pEGWjMgon6ryIGrUmw0apgEnClHuZdc14vDdsoI0VcqC3VoxbeEd0Z2C9+gr GpXbbfjZWc7iRXQiujXCX5jq9IeM09+I4/DcG1DyPnONrxo2gqXPeJijVQwcld6uz7+9 s8hw==
X-Gm-Message-State: APjAAAXAEX0AsnIbGDuRByXEBDKJtXcoasrF+cyBb0JMkPTygtn4IGmb MZScc1wiW7ljkRrwE7fUG4h+9GrJ2EPvY3O71Wg=
X-Google-Smtp-Source: APXvYqwyPzAgkXqJ07izzFiFrwV8CsjJ6MsiCor4lIFYaIHlxl98brukIFlqCM6jp00jDt3C1pOtfBK9R9/ZIqbPh1Q=
X-Received: by 2002:a19:10:: with SMTP id 16mr13687048lfa.100.1571809176268; Tue, 22 Oct 2019 22:39:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Tue, 22 Oct 2019 22:39:24 -0700
Message-ID: <>
To: Rob Sayre <>
Cc: "Salz, Rich" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 05:39:41 -0000

On Tue, Oct 22, 2019 at 7:54 PM Rob Sayre <> wrote:
> 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 idea.

Padding to the max every time leaks no information. It also doesn't
have some of the operational issues. There are possible setups on
Cloudflare where Cloudflare will not know what domains are being
proxied ahead of time (wildcard DNS+wildcard cert,
available to enterprise customer)

What's not clear is what the other proposals leak. Some of them like
randomized padding end up leaking much more the might be expected.

At the same time Client Hello sizes aren't constrained to be tiny, but
the next problem of 1280 bytes is not that far off either. So we
should be judicious in spending those bytes.

> thanks,
> Rob
> _______________________________________________
> TLS mailing list

"Man is born free, but everywhere he is in chains".