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

Hugo Krawczyk <> Wed, 20 July 2016 05:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 971F012DA7A for <>; Tue, 19 Jul 2016 22:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 IBwqCt-ntmIN for <>; Tue, 19 Jul 2016 22:43:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 966C112DA82 for <>; Tue, 19 Jul 2016 22:43:28 -0700 (PDT)
Received: by with SMTP id j12so29203070ywb.2 for <>; Tue, 19 Jul 2016 22:43:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CxdmZ6fK/dVlw/sVjzGMkfMD2RozZvJJ7EtMyPjwHmc=; b=wtYHF5YsEHz33Nim6SOFa1WvnIlsA4KzovIR2NpH76FxAaSYv00pWrirXXGANox4L6 1dfChvTHiUFak4mi1nv4x3TsQv3BGYdSGgaIprNON5qhfJ6Nq3e3gFRNhaLJq9+z9otV JRXTzfPMK2OPVnYZfPPz3r+iOmLk2UNcppSzdTW5iJBxNMuBDHm/CJP+i1HSMWFVu+Lt cRDWWMnWGXW7HfbWH+7WtyzD5YIgCCPFV80e04FxNO3MMHWdnK67OCNRQ9coJqOhVXp8 kYuIQN+AcO48149CHgC2xxFBSgFBaD7q8v+/VtfKnove13c4aoWDzmJdwp0yzJ3YG6fv +nhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CxdmZ6fK/dVlw/sVjzGMkfMD2RozZvJJ7EtMyPjwHmc=; b=Znp3GAQaQ1gPwzVR1iL9ewtykKZwJJFy31prOovIsftluExwhyIgQ/KoqgR7Vu+Wnz kYpoQcHm2vTO7rRXidVxhjjzLmiX5y6g0FN09pARNsNUzg9Un+a1s05JcKCYgFwVQ69f yepJzRMyHoapogaXIqXxW84cYmn/ZfeKbBP5c7a6r3GDXeYmrerr3aomw31uXM1x/ttd ChLgyBnyrmz0kJqv0dA4d0joj26HBrRmIykimFIfcP48DTaQ6RYLAHdceF8XdAUE8jsb EucvWp8+X5M36OjSNcleUvrfkBrPyBaP7T85pVsvD7Oy3R7i+zViCFoDes/clK0EojJB L3vw==
X-Gm-Message-State: ALyK8tKa6qNTXooVdAOj8oGWSBrAY2hVLlgf9Q8xveyirq2oHKhHBmKswuLtFC6/jCXUOo39h6HdKYdOkzgVow==
X-Received: by with SMTP id w65mr18890613ywe.128.1468993407788; Tue, 19 Jul 2016 22:43:27 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 19 Jul 2016 22:42:58 -0700 (PDT)
In-Reply-To: <013101d1e1cc$253eddb0$6fbc9910$>
References: <> <013101d1e1cc$253eddb0$6fbc9910$>
From: Hugo Krawczyk <>
Date: Wed, 20 Jul 2016 01:42:58 -0400
X-Google-Sender-Auth: gSQFjxQdMGyuTlSMbndHChLTG3I
Message-ID: <>
To: Antoine Delignat-Lavaud <>
Content-Type: multipart/alternative; boundary=94eb2c0887443fae4505380aaee7
Archived-At: <>
Cc: Karthikeyan Bhargavan <>, "" <>, Markulf Kohlweiss <>
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: Wed, 20 Jul 2016 05:43:35 -0000

Without taking a position on the implementation issues, I am in favor of
Option A with a dedicated context value (and an explicit name "PSK
Context") as this makes clear the function of this value. Relying in
Finished makes it more fragile and open to be dropped in the future when
its binding role is "forgotten" or when deriving some other protocol or

Also, I insist on the need to remark about the need for collision
resistance of any value with a binding functionality. If this value is
produced with HKDF (or HMAC as in he case of Finished) the need for
collision resistance is not explicit and can lead to truncation (which is
perfectly fine when just deriving keys or when used with a regular PRF

Actually, I would suggest that for any such value, we add "collision
resistance" to the label for that derivation - this would apply to
resumption/PSK context and to Exporter key (and possibly others)


On Tue, Jul 19, 2016 at 10:45 AM, Antoine Delignat-Lavaud <> wrote:

> Dear all,
> Here is an extended summary of the early Finished / resumption context
> discussion at the WG.
> 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.
> At a high level, this means that there is no crypographic binding between
> the handshake log (what is signed for authentication) and the PSK used in
> the key exchange.
> In the resumption case, the resumption context fills this role (which is
> the
> reason why it was introduced); however, all external PSKs currently have
> their resumption context set to 0 (and thus, all logs are equivalent w.r.t.
> all non-resumption PSK).
> Since the handshake log is what get signed during certificate-based
> authentication, the lack of binding
> means that a signature from a session s1 can be used in a session s2 as
> long
> as the PSK identifier are the same, which is a very weak constraint.
> 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). For those of you who were at TRON, you may
> remember that Karthik made this point quite clearly in his talk (he even
> proposed to swap CV and Finished for this very reason!).
> An attack against external PSKs easily follows: we assume that an attacker
> A
> wants to impersonate a server S to some
> IoT-like client C that can only do pure PSK for key exchange.
> 1. C registers to A under the PSK identifier Xc. The PSK between C and A is
> Kca
> 2. A, acting as a client, registers to S under the same identifier Xc. The
> PSK between A and S is Kas
> 3. C connects to A using (Xc, Kca). A forwards the ClientHello to S
> 4. S sends back ServerHello, [EE, Cert(S), CertVerify, Finished]_hs where
> hs
> depends on Kas and the log [ClientHello, ServerHello]
> 5. A forwards ServerHello from S to A and re-encrypts [EE, Cert(S),
> CertVerify] under hs' which depends on Kca and [ClientHello, ServerHello]
> 6. Since all logs are synchronized and nothing in the CertVerify depends on
> Kca or Kas, C authenticates A as S.
> 2. Proposals to bind log and PSK
> As pointed out by Karthik months ago (and by myself years ago, in the
> context of Triple Handshake), implicit authentication (such as PSK or
> resumption) is difficult to mix correctly with transcript-based signatures.
> We have considered several ways to ensure uniform security for all PSK
> modes.
> The simplest solution (let's call it option A) is to rely on the draft 13
> resumption context infrastructure also in the case of external PSK.
> Put it simply, externally-provided PSKs are treated as if they were
> resumption master secrets: if K is the external key, we first compute
> Ek = extract(K, 0), then PSK=expand(Ek, "external psk") and RC=expand(Ek,
> "external psk context").
> Resumption context is renamed PSK context and PSK and RC are used as in the
> current draft13 key schedule.
> While option A does the job, we think it is over-complicated, as we observe
> that the early finished can actually play exactly the same role as the
> current resumption context (saving the concatenation with rc in every
> expansion with an handshake log).
> 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.
> I have thought more about this, and I now agree that this makes option B
> unpractical.
> We are left with some more options: one would be to swap CertificateVerify
> and Finished, as Karthik originally suggested.
> Another would be to have a Finished immediately after ServerHello. Neither
> of these alternatives is particularly appealing,
> and it may be the case that option A is in fact the better choice.
> Best,
> Antoine
> -----Original Message-----
> From: TLS [] On Behalf Of Ilari Liusvaara
> Sent: mardi 19 juillet 2016 15:46
> To:
> Subject: [TLS] Resumption Contexts and 0-RTT Finished
> Thinking about this...
> One option would be like 2 on the slides (the overstriked one!), except:
> - The message is synthethized, not actually sent on wire (but still
>   logged).
> - It only happens after the last ClientHello.
> - It uses the actual PSK, even if not #0.
> Maybe I should have listened to the talk more carefully, but the reason I
> got for overstriking the second option was that it is unimplementable in
> practice.
> Of course, dunno if the changes would actually fix the problems with PSK
> contexts...
> -Ilari
> _______________________________________________
> TLS mailing list
> _______________________________________________
> TLS mailing list