Re: [TLS] Finished stuffing

Ilari Liusvaara <> Fri, 09 September 2016 08:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 603DF12B0DB for <>; Fri, 9 Sep 2016 01:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.408
X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2hLnCuhjgNGS for <>; Fri, 9 Sep 2016 01:22:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 12B5012B08C for <>; Fri, 9 Sep 2016 01:22:42 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE7D7F28E; Fri, 9 Sep 2016 11:22:40 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id NdTmt4qrtFFT; Fri, 9 Sep 2016 11:22:40 +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 86A862315; Fri, 9 Sep 2016 11:22:40 +0300 (EEST)
Date: Fri, 09 Sep 2016 11:22:38 +0300
From: Ilari Liusvaara <>
To: Hugo Krawczyk <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: NeoMutt/ (1.7.0)
Archived-At: <>
Cc: Antoine Delignat-Lavaud <>, "" <>
Subject: Re: [TLS] Finished stuffing
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: Fri, 09 Sep 2016 08:22:45 -0000

On Thu, Sep 08, 2016 at 09:59:22PM -0400, Hugo Krawczyk wrote:
> On Thu, Sep 8, 2016 at 5:29 AM, Ilari Liusvaara <>
> wrote:
> > On Wed, Sep 07, 2016 at 07:43:53PM -0400, Hugo Krawczyk wrote:
> >
> > - The hash has output length at most input length (true for all SHA-2
> > variants)
> >
> Just curious: Can you explain the need for this property? Note that if a
> key to HMAC is  ​larger than the (compression) function output size then
> this key is first hashed into a full output hence preserving CR.

Simply me not bothering to figure out what the heck HMAC does if this
isn't true (or if it is even well-defined in all cases).

> - HKDF-extract salt length is constant (in current draft, always hash_olen)
> > - HKDF-expand PRK length is constant (in current draft, always hash_olen)
> > - The HKDF-expand output output length is at least hash output length
> >   (in current draft, hash_olen except in key expansions).
> >
> These are a lot of restrictions that no one has spelled out as conditions
> on the KDF and they do not follow from the natural properties of KDFs.
> Collision resistance is never needed as far as I can tell for generation of
> keys or to compute PRF and/or MAC values (e.g., for the original
> functionality of Finished that is essentially a MAC/PRF on the transcript).
> The reason we find ourselves considering the CR properties of HKDF is that
> we are using it to derive *strings* that serve as binders/digests of past
> transcripts. Luckily, HKDF with the right hash functions can provide that
> functionality but it is not a native KDF functionality.

So I presume some more text for Security Considerations...
> I do not mean this as an academic discussion (although we could have that
> too) but as a warning for future (if not present) misuse and an obstacle in
> replacing HKDF in the future.
> I would be much happier if we had a clear distinction between PRF/MAC
> ​computations, KDF computations and digest computations., even if we
> currently used HKDF for all these functions.

Unfortunately there are things like exporter outputs, that need to be
both "secret" (i.e. "keys") and "nonces" (i.e. "binders"). At least if
application wants so... Dropping either would cause MAJOR security

I think those and the dynamically provisioned PSKs are the only ones
that have that property of being both key and binder.

> > It is a bit more problematic than that:
> >
> > The hello_finished / "PSK Creation Binder" derives from the PSK key.
> >
> > Deriving separate value in context of dynamic PSK provisioning does not
> > work properly as "static" PSKs lack this value, and if one then tries to
> > use such key with combined authentication, you got an attack[1].
> >
> ​I could not follow this argument.
Basically, one can't make a distinction between static ("non-resumption)
and dynamic ("resumption") PSKs here. Because such distinction would
run into security problems with some other features.