Re: [TLS] Resumption Contexts and 0-RTT Finished

Ilari Liusvaara <> Tue, 19 July 2016 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67AA812D0E5 for <>; Tue, 19 Jul 2016 09:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bVAxKWVqizet for <>; Tue, 19 Jul 2016 09:37:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D15BE12B04F for <>; Tue, 19 Jul 2016 09:37:38 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F5CA4820; Tue, 19 Jul 2016 19:37:37 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id c55pwJ2lcFoD; Tue, 19 Jul 2016 19:37:37 +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 EE72C2310; Tue, 19 Jul 2016 19:37:36 +0300 (EEST)
Date: Tue, 19 Jul 2016 19:37:32 +0300
From: Ilari Liusvaara <>
Message-ID: <>
References: <> <013101d1e1cc$253eddb0$6fbc9910$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <013101d1e1cc$253eddb0$6fbc9910$>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <>
Subject: Re: [TLS] Resumption Contexts and 0-RTT Finished
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: Tue, 19 Jul 2016 16:37:41 -0000

On Tue, Jul 19, 2016 at 04:45:01PM +0200, Antoine Delignat-Lavaud wrote:
> 1. Signature forwarding with external PSK
> Currently, resumption context is only defined for resumption-based PSK,
> which means that external PSKs are not protected against transcript
> synchronization attacks.
> Before Cas Cremer's paper, this was particularly bad because the Finished
> (which is bound cryptographically to the PSK) was not part of the handshake
> log; therefore, all signatures could potentially be replayed.
> However, even though Finished are now part of the log, the server signature
> in PSK 1-RTT remains vulnerable (because the log is then ClientHello,
> ServerHello, Certificate and thus has no Finished message to save us from
> transcript synchronization).

Oh yeah, that.
> 2. Proposals to bind log and PSK
> As an option B, we propose to always include an early finished in the log,
> regardless of the handshake mode.
> This comes with some complications that were discussed during the WG
> meeting. Very notably, if this early finished is assumed to always come
> after the ClientHello, then it must either a. mangled with the ClientHello
> in an ugly way or b.send on the wire at all.
> During the WG meeting, it was pointed out that regardless of whether a or b
> is used, if the client proposes more than
> one PSK, there needs to be more than one early finished.

What about never sending it on the wire but still having it in hash just
before ServerHello, using the actually used PSK key and PRF and logically
sent by the client.

Placing it before SH instead of after CH is because of interactions with
restart/0-RTT. The logical sender matters for DTLS (uses message number
on which side?).

- Binds PSK into the log (dealing with the attack above)
- Friendly to TLS 1.2 servers.
- Can be made up on the spot, no need to compute multiple, no need to
  speculate (even if speculating on PSK).

- Special case of message being hashed that doesn't appear on the wire,
  no percedent for this (only hs messages on wire not appearing in
- Can't be easily included in 0-RTT keymat. But then, seems kinda
  pointless to include it, as 0-RTT keymat already depends on all the
  same inputs (PSK#0 and CH).

Of course, no idea just how nasty implementing this in various TLS
stacks would be... Could be very nasty...