Re: [TLS] Finished stuffing

Ilari Liusvaara <> Sat, 10 September 2016 07:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87D5112B04F for <>; Sat, 10 Sep 2016 00:35:09 -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 LCJTOu0SvvCE for <>; Sat, 10 Sep 2016 00:35:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 63B6112B00A for <>; Sat, 10 Sep 2016 00:35:06 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50C921409D; Sat, 10 Sep 2016 10:35:05 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id BezRJXHjmV_5; Sat, 10 Sep 2016 10:35:05 +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 02254C4; Sat, 10 Sep 2016 10:35:05 +0300 (EEST)
Date: Sat, 10 Sep 2016 10:35:03 +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: "" <>
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: Sat, 10 Sep 2016 07:35:09 -0000

On Fri, Sep 09, 2016 at 07:33:21PM -0400, Hugo Krawczyk wrote:
> On Fri, Sep 9, 2016 at 4:22 AM, Ilari Liusvaara <>
> wrote:
> ‚ÄčI would much prefer to have two elements associated with such keys. One is
> the key itself and the other is a binder (or whatever other name one
> chooses for it) that consists of a context string or digest associated to
> that key. Then, you would use the key to key crypto algorithms and use the
> descriptor as a binder to the key's original context, usually as input to a
> crypto algorithm (and not as a key). This will make the functionality of
> each element (key or binder) more explicit and will make it clear when is
> that we need collision resistance and when we don't.
If one can really have PSKs that lack "binders", then one would really
need to ban nontrivial authentication with those PSKs.

That is:
- If the PSK lacks a "binder", then:
  * Client MUST send auth_modes = [psk_ke] (i.e. 0x01, 0x00) with such
  * Server MUST abort with illegal_parameter if anything else is sent.
  * Client MUST abort with insufficient_security if the server tries to
    use any authentication mode except psk_ke.
  * Client MUST NOT send either early_data or hello_finished/hello_binder
  * Server MUST abort with handshake_failure if either extension is
- If the PSK has a "binder", then:
  * hello_finished/hello_binder extension MUST be present and have the
    correct value.
  * If it is not present, server MUST abort with missing_extension.
  * If it is incorrect, server MUST abort with decrypt_error.

(The point of all those "MUST abort" requirements is to try to weed out
implementation that might do unsafe things to the extent possible).