Re: [TLS] Issue 555: Generate IVs in one HKDF invocation?

Ilari Liusvaara <> Thu, 18 August 2016 05:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B97D212D0FD for <>; Wed, 17 Aug 2016 22:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qUdY3UwBUGKn for <>; Wed, 17 Aug 2016 22:24:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1017412B015 for <>; Wed, 17 Aug 2016 22:24:18 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98DABF568; Thu, 18 Aug 2016 08:24:16 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id TW2wIq5QwTdx; Thu, 18 Aug 2016 08:24:16 +0300 (EEST)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id F4160C4; Thu, 18 Aug 2016 08:24:15 +0300 (EEST)
Date: Thu, 18 Aug 2016 08:24:07 +0300
From: Ilari Liusvaara <>
To: Eric Rescorla <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.2-neo (2016-08-08)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Issue 555: Generate IVs in one HKDF invocation?
X-Mailman-Version: 2.1.17
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: Thu, 18 Aug 2016 05:24:21 -0000

On Wed, Aug 17, 2016 at 03:09:51PM -0700, Eric Rescorla wrote:
> Issue:
> ADL suggested that we could slightly reduce the number of HKDF
> computations by generating the IVs as a single block rather than
> with individual HKDF-Expands. You can't generally do this kind
> of slice-and-dice and preserve the key boundary, but IVs are
> public anyway.

Except that actually usefully make IVs public (without it just being
pointless disclosure), you would need MRAE, which is strictly stronger
notion that AE(AD) required by TLS. Neither GCM nor Poly1305 are
MRAE (and I don't think CCM is either).

Basically, doing generic encryption with AEAD is not possible. One
needs protocol-specific knowledge. This is because of the disaster
that repeating nonce is. TLS 1.3 protocol-level prevention of
duplicate nonces does not help any here.

> At least for NSS, this makes things slightly more complicated
> because we generate the directional traffic keys independently,
> but it's also not a big deal to change if people want.

And yes, this makes code that generates the directions independently
(which is reasonable thing to do even for simple implementation)
quite much more annoying, as one needs to slice the IV buffer.

I don't also expect this to improve performance any: The code
will probably still generate directions independently, not saving
the other half of the IV, so it needs to be recomputed when the
other direction is computed. 

So complicates code for no actual benefit.