Re: [TLS] predictability of inputs in ESNI

Eric Rescorla <> Fri, 01 November 2019 22:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64916120801 for <>; Fri, 1 Nov 2019 15:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 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, 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 asIiVUQZbkW6 for <>; Fri, 1 Nov 2019 15:40:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0DBCF120828 for <>; Fri, 1 Nov 2019 15:40:00 -0700 (PDT)
Received: by with SMTP id y6so8293070lfj.2 for <>; Fri, 01 Nov 2019 15:39:59 -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=Y0WchmENDLLHDWq2K4XrxNJ/mJ2KtFSr50yDbUtKpFI=; b=HJq4Dt3ClAoQj3YyB5j55hK4XnVsYin0YoUYiBygNGDqxMEXgfd44Q0OMgqFIDJCjX bTkAyPWNCtp6R7jEkSTzaW916tDtvxFUitry3rbbPJHLG5DZYJOU2+KYK616RS6CfO2X gTDdnI2RJcUshSSiXGlUcaxkazlNTEE4jKRnGAcRoI4hJNXBGmdzxnOnLoACsebGtbFh woQwwR95libhtJ7XW/h768wbWF8uHFfOytr6BUj6UB5ohFXTyMxs9OAKLxz1u+bmv4zP XChb2UvW157HEhfraw7clNTUpHE61KeJQq2lFFMSDrgxGZT4e9W3X9PrFDd+iEr4fm0q d+wg==
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=Y0WchmENDLLHDWq2K4XrxNJ/mJ2KtFSr50yDbUtKpFI=; b=et4L3ONn+SyF3M8/IFDV41/ZAdF2BJ6YAZnHMTac+ISC2sjdoUwZATDH5BU7ET5vZ0 46sQySzBsIiJ4C5lY3WzX+h4XKPzyxXGphVJuXTWjst35wqYM5nqJXXHKRnRSmeSl6en 9nEshBhUA+L3owTvAdsCApKgaDeVKw/OJcJj97VlvGNOUwlEG7AKAYUiVn3hLZeVmj5k xnxyXEYjJcO+wbY0Yq9gcTzh+aYvdp/KmYh7grZfz1MmbxQB9Qo3I8MhjzNaUM/CyPoJ d6wtm+J8qblRI7BNvsC6ugBZZMOFQ8YT4/V2CN7MjVY8KszaClO6n4gKI6VQob57nQbo I+PQ==
X-Gm-Message-State: APjAAAW9gWXolZpwYufsweBu0/OG6B9GPn8erDnBhmHp56zYRsFd0E85 LOxqjMsE5AQRrduBtA9gBlGt2coDyXYKVzf5uBOQoQ==
X-Google-Smtp-Source: APXvYqzQ5I7Za4cI4rDNti7zbZ6cO7px83hZd9lvs1rVOChDzCnxaaDjSos93x3TkLUL8NZ0KLr99ziwyQACRs9PaQo=
X-Received: by 2002:a19:c6d6:: with SMTP id w205mr8036254lff.17.1572647998373; Fri, 01 Nov 2019 15:39:58 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Fri, 1 Nov 2019 15:39:22 -0700
Message-ID: <>
To: Rob Sayre <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000004cd7d6059650a59a"
Archived-At: <>
Subject: Re: [TLS] predictability of inputs in ESNI
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: Fri, 01 Nov 2019 22:40:12 -0000

On Fri, Nov 1, 2019 at 3:27 PM Rob Sayre <> wrote:

> On Fri, Nov 1, 2019 at 3:09 PM Eric Rescorla <> wrote:
>> On Fri, Nov 1, 2019 at 2:28 PM Rob Sayre <> wrote:
>>> Hi,
>>> I am not sure how important these findings are, but I've noticed three
>>> instances of unnecessarily predictable inputs in ESNI:
>>> 1) Trailing padding after domain names are zeros.
>> 2) The checksum calculation seems to start with predictable version bytes
>>> in draft -04, and in shipping implementations
>> I'm not aware of any cryptographic reason why these would be a problem.
>> It's reasonably common practice to have partially fixed inputs to the TLS
>> cryptographic functions (see, for instance, HMAC labels and the trailing
>> padding 0s in the record protection). In general, if this sort of thing
>> turns out to be a problem for some algorithm, we consider it to be a
>> problem with the algorithm.
> I see. But is there any reason to make these inputs predictably zero by
> spec?

Absent some reason not to, this seems like a reasonable design choice. At
minimum, it has the advantage that it's easy to detect some classes of
implementation errors.

3) In practice, NSS inserts 8 bytes of zeros at the beginning of its AAD
>>> input (<>)
>> I believe you're misreading the code. For historical reasons, the
>> internal NSS TLS AEAD API prefixes the AAD argument with the sequence
>> number. When we repurposed this code for ESNI, we just passed in a 0
>> sequence number. That value is stripped off and is not part of the AAD
>> computation.
> I see, so you're saying that NSS adds 8 bytes to the AAD input, and then
> strips it off at some later point?

No. I'm saying that the function argument is called |additionalData| but
that's not what's used as AAD in the actual cryptographic function.

I wouldn't exactly call that misreading.

This seems like a definitional question that is not worth debating.

Maybe something to fix?

This is not on topic for this mailing list. This internal interface is
quite old and when we wrote the TLS 1.3 code, we considered changing it and
decided it wasn't worth it. If you'd like to submit a CL to NSS which
improves this, we'll take a look.