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

Rob Sayre <> Mon, 21 October 2019 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0204F120043 for <>; Mon, 21 Oct 2019 07:56:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 z8fYaTkyg8ut for <>; Mon, 21 Oct 2019 07:56:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3974120096 for <>; Mon, 21 Oct 2019 07:56:01 -0700 (PDT)
Received: by with SMTP id 1so4918640iou.4 for <>; Mon, 21 Oct 2019 07:56:01 -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=qWO05rT49YCqytvz2oY2rde4EgJNWaw+APa+rjUEmow=; b=nhOkeOveTXA3J/oecyUFvdT2YSlH5CtQHP2HGVlhchCXaPMIWG0Za6zXqEalQQ6pqa mVkerSpYIQ08vRtgZrPPfNeDjrh+/payGQC1Ko8yWjoI5tfXrc/DiEvFPKdiZfhxrgao u5Sp+9do1eluk8XmWehJtxfjegjV90tnHWj1R1iZ59ZPzyiS0kGJXEEw7qRpYXRdqXv8 EyrslNE+avfArGQJyos7z05yJV9YJNS9XdxWt1rhc3poFIVTjsABVL8+GXvRkfZtx7OE D7ZTX/E3EIiAWiMO0P2hrmKokxzj0ZiFYlyBTyVshYZGXi/UsNYLQ8gdt8GSp6/adjve ThoA==
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=qWO05rT49YCqytvz2oY2rde4EgJNWaw+APa+rjUEmow=; b=DcRh4gbYVY2YVcbzMhRRCbVgbX/sI2ARPyVnDdTtX0Ve8AhmM7W3hFSVy8inTKpsrK XrfDr/F6t/Bxxt3U3ulJ8vyJnUKEiCqZoOOTejp3jYGfbY+ufNspdEhPctM8+gU+ypnM ipqlryWfJeLApAY2esTCcyWOfgaq8s6hxZZGDQy2BSlvDGh6vzadDCRuE8GrRqm4vypB Uo+hoJ0b3U+nWReOz70mVEEFVRTn8jH0KMkB0a+kQT8cifSIXFQ3kNsaBG+zlLPAKbSN 2/E5mu3wU+1H8QM+lqBYmB2b1PTS0xWZloLZPwlTHDSc4D98sCNkQ5KSxNR29Y5TSKAw PwhA==
X-Gm-Message-State: APjAAAXI0oMttxNxbTu0kjFBgG02ieJ1J3xg7fQS0ItwZ5gN1Ip8Xebo lxvgUKja5zSUn6Oz4htLqwe26YeokACINx9wUnqNHMRl
X-Google-Smtp-Source: APXvYqwN59URPknCZ/5ME0YjZ7SVCtIo6A72AlW5EDDIv3ot0HVBhP2IF11R2lf2zcKdheBnrv557BANjzTaqYvJq8E=
X-Received: by 2002:a6b:400e:: with SMTP id k14mr9653375ioa.254.1571669760774; Mon, 21 Oct 2019 07:56:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Rob Sayre <>
Date: Mon, 21 Oct 2019 07:55:49 -0700
Message-ID: <>
To: Eric Rescorla <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000cb952005956ce1af"
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 14:56:04 -0000

On Mon, Oct 21, 2019 at 7:41 AM Eric Rescorla <> wrote:

> On Mon, Oct 21, 2019 at 7:32 AM Rob Sayre <> wrote:
>> Judging by the mailing list archives, the design of the field is
>>>> intentional. It's not clear to me why "zeros" wasn't specified as
>>>> variable-length with a prose restriction, though.
>>> Because then you have a spurious length field.
>> I don't understand why it would be spurious. In this case, the
>> deserializing implementation needs to inspect every byte anyway.
> Because if you set padding to be the length of the maximum value, then a
> length byte makes every message one longer.

Sorry if I'm being dense here. Couldn't "zeros" have a length? Maybe you
just mean it would be superfluous. That could be true, but it is dependent
on the value of a field in a DNS record. If it had a length, I could have
used existing payload deserialization code.

Having gone through every message in this draft, I don't understand the
rationale behind the following section and the corresponding

CipherSuite cipher_suites<2..2^16-2>;
uint16 padded_length;


padded_length : The length to pad the ServerNameList value to prior
   to encryption.  This value SHOULD be set to the largest
   ServerNameList the server expects to support rounded up the nearest
   multiple of 16.  If the server supports wildcard names, it SHOULD set
   this value to 260."

That's not to say the draft is wrong, but the rationale seems missing. The
rationale may exist in a mailing list message or github issue.