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

Eric Rescorla <> Mon, 21 October 2019 18:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 080F8120105 for <>; Mon, 21 Oct 2019 11:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 PqxmnKJrJwGi for <>; Mon, 21 Oct 2019 11:09:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 894401200E0 for <>; Mon, 21 Oct 2019 11:09:31 -0700 (PDT)
Received: by with SMTP id m7so14380233lji.2 for <>; Mon, 21 Oct 2019 11:09:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fQ9w71+zyg+5pcC9dMGh4vXAjEqHFO2oUaffgTbOqLQ=; b=z2iq7dKD3RutqmuHS7TngZozOy19f65/5X+XBWNLnqUaOWAhoOeMZytJTBHZXaESqG FuIINzlmLm1Olfa7SaD+Nd77p4WIQzQay38FokJoALK777HFmOzVGX2uaSuipR364EbW g3TD3HKhI5YdjBAZSCqHgZPSxF7MdEYMa6/tO3Bykmk9kUfmh4h7hZnSjAVdHuDCUgHr 9RWejpSbAxAdjuKgH6a7+xxSLy/1gg+pKUe1+ddXjr25hVH9RoEkSozlx3fPxbYzEhtR WS5R8o09Fm8JRsx48hq1tk5Z0XOwPgXluuyIWtEf46G/qF2+pk7NjUiv0Syw4/f83XNt ajHw==
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=fQ9w71+zyg+5pcC9dMGh4vXAjEqHFO2oUaffgTbOqLQ=; b=HhVEr3Jm16t9GpF2S2Im/yAQjegTkCuIcItUxqbmcStSCq26N1VxoTfbclDVAr4Er+ fWuPPkT7jiuaIPvctLuSREc8OchWJRef92dYEU71iwQrGR4UpeyemDNIeuk6f2IQbuno dNf6KVm/W91R3U9fePwTtLq1eUiOqyAFHE0M7AAoI2pc86Fw/EpN6V84S/jtzcNWRzn4 9mVW9htNwuqZfuDWesX3M44J0FwyHW1YFPXPunTJkuKcUJVap4r26jzcz9NQ/oqXxaQV OJFMkMSAo2/SSqBwAay/4qr5TtkWMMaCRGxmeQTTWACZoGGo++d1lES535wxOuXDkYSt jNfA==
X-Gm-Message-State: APjAAAVjAEHJT3Oir2nGkwe0PTAwnbQR+LrjUALIT33GWufj10tRVTl6 Wh4lrFcHY2OTcwQn5gjLPjii+vOes8JQx8GKMjVF+A==
X-Google-Smtp-Source: APXvYqzHCIkZMLDiQUXxIr3eEHvRThpsHPIg/Zgm1Gjl+mqVTsfp0oUEZXERiXiz4HJZdov6UestZo8p/3DPyGfuPDI=
X-Received: by 2002:a05:651c:237:: with SMTP id z23mr16036803ljn.93.1571681369731; Mon, 21 Oct 2019 11:09:29 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Mon, 21 Oct 2019 11:08:53 -0700
Message-ID: <>
To: Rob Sayre <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000be4eb005956f9538"
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: Mon, 21 Oct 2019 18:09:34 -0000

On Mon, Oct 21, 2019 at 10:55 AM Rob Sayre <> wrote:

> On Mon, Oct 21, 2019 at 9:45 AM Eric Rescorla <> wrote:
>> On Mon, Oct 21, 2019 at 7:56 AM Rob Sayre <> wrote:
>>> Sorry if I'm being dense here. Couldn't "zeros" have a length? Maybe you
>>> just mean it would be superfluous.
>> Yes, that is what I mean.
> OK. To be clear, I understand why there is padding in the spec. I don't
> understand three aspects:
> 1) Where did the number 260 come from? It also seems to conflict with the
> "multiples of 16" advice in the previous sentence.

I believe it was large enough to fit the maximum plausible label size, but
I'd have to go look at the relevant issue.

2) Why does the server set the padding amount? If clients were allowed to
> vary it with different amounts of zeros, wouldn't that be more anonymous?

No. You want padding to be set to be the longest size that you would send
to any origin in the anonymity group, and the server knows this. Many
client padding strategies leak information over time and it's hard to know
how to construct one that doesn't unless you know the max. For instance,
consider what happens if the anonymity group consists of "a.example" and "" and the client always pads to the next 16.

3) Why is the length of "zeros" implicit rather than explicit? Is it to
> save a few bytes, or is there a deeper reason?

It saves bytes on the wire. It's also the way we've done other zero padding.

None of this stuff signals a flaw in the draft from an interoperability
> perspective--I was able to follow it as a non-expert in TLS and get things
> working. But I still have questions about why things are specified this way.

Generally speaking, these issues were aired on the list or in Github
issues, so the best way to answer them is to go look at the history


> thanks,
> Rob