Re: [TLS] Resumption Contexts and 0-RTT Finished
"Antoine Delignat-Lavaud" <antoine@delignat-lavaud.fr> Tue, 19 July 2016 15:09 UTC
Return-Path: <antoine@delignat-lavaud.fr>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0022112DF80 for <tls@ietfa.amsl.com>; Tue, 19 Jul 2016 08:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=delignat-lavaud.fr
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tJVQo4d6Sdy for <tls@ietfa.amsl.com>; Tue, 19 Jul 2016 08:09:19 -0700 (PDT)
Received: from argon.maxg.info (argon.maxg.info [IPv6:2001:41d0:2:7f22::1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360E512DDA3 for <tls@ietf.org>; Tue, 19 Jul 2016 07:45:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=Ti/WBKNfnBa0B8os0RmHDi9LCh9RGu07XmKh3HWxoX4=; b=JQ/fWYUm6h99XqzQOJUZq5H8U1HmhSxMacMt87elCVwlZ+4TZTiLXTT+tzvg12JytAMehunbWs3xDqN0Oj+OLHK33xvRFFwJeqeeN7eGg0CZHNI9Om+Lhnd78ijDmirvqas48ZqiP3jC67uzlJKmHdV7v54A+zx5KX1qwK/EO8EjkdMezPwo5ecrVYWyGL2B3ayrXfpmGs0kYH/3o3cIQqf6RQXfAP6HXI4IFo1v8E5Xe7w/asys6dOTFVS8XyGjYwj2NtxT50VISY4rB6HwgMwGEu/85AzToAMPoO2J5begGvmOa7gxICmIU0Dj7VdUYRMHQeJEneeL0Pxd/C9yrA==;
Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (envelope-from <antoine@delignat-lavaud.fr>) id 1bPWGh-00078M-7s ; Tue, 19 Jul 2016 16:45:08 +0200
From: Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr>
To: 'Ilari Liusvaara' <ilariliusvaara@welho.com>, tls@ietf.org
References: <20160719134626.GA14259@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20160719134626.GA14259@LK-Perkele-V2.elisa-laajakaista.fi>
Date: Tue, 19 Jul 2016 16:45:01 +0200
Message-ID: <013101d1e1cc$253eddb0$6fbc9910$@delignat-lavaud.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG9/e1dQJA4pkpRlO4rMyjbOzdXDaBHmdxg
Content-Language: fr
X-Invalid-HELO: HELO is no FQDN (contains no dot) (See RFC2821 4.1.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XPNUvM1wlLFmrHxydTUAvv6baig>
Cc: 'Karthikeyan Bhargavan' <karthik.bhargavan@gmail.com>, Markulf Kohlweiss <markulf@microsoft.com>
Subject: Re: [TLS] Resumption Contexts and 0-RTT Finished
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jul 2016 15:09:23 -0000
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 [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara Sent: mardi 19 juillet 2016 15:46 To: tls@ietf.org 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@ietf.org https://www.ietf.org/mailman/listinfo/tls
- Re: [TLS] Resumption Contexts and 0-RTT Finished Ilari Liusvaara
- Re: [TLS] Resumption Contexts and 0-RTT Finished Hugo Krawczyk
- Re: [TLS] Resumption Contexts and 0-RTT Finished Ilari Liusvaara
- Re: [TLS] Resumption Contexts and 0-RTT Finished Eric Rescorla
- Re: [TLS] Resumption Contexts and 0-RTT Finished Antoine Delignat-Lavaud
- Re: [TLS] Resumption Contexts and 0-RTT Finished Eric Rescorla
- [TLS] Resumption Contexts and 0-RTT Finished Ilari Liusvaara
- Re: [TLS] Resumption Contexts and 0-RTT Finished Benjamin Kaduk