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

Eric Rescorla <ekr@rtfm.com> Tue, 19 July 2016 15:40 UTC

Return-Path: <ekr@rtfm.com>
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 6806F12D971 for <tls@ietfa.amsl.com>; Tue, 19 Jul 2016 08:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 h75kCJjMgGXN for <tls@ietfa.amsl.com>; Tue, 19 Jul 2016 08:40:16 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72DA12DC39 for <tls@ietf.org>; Tue, 19 Jul 2016 08:25:03 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id u134so18506610ywg.3 for <tls@ietf.org>; Tue, 19 Jul 2016 08:25:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZB8uaH47tlHMfa+ir70KGeuEZgNNNt12CRoSphH8LbE=; b=jemn5xdsKdqNoAuqVuutuqNe2n3X8/0J82Pij23UPtbwLYEbk8GQBFc3MD9SrqJPat 0C/TMKnERDETJld4txLrTksnMw4iD9ZPa59IsH3Vn2EnJ7qs/2bvWjuSfLGgyjdhb3m3 bizxBAn21fGQ4qspz69sx042gSp/y++U2AUUUqDKxu6enz+hrRNzxxWlhWXT96X4+CHH 3dgwh0BYAJbrfBZ3Ot6t4dpr73XraE7RBYzZSrfFInMDCc0mfX4zCpnQTgr6pUZfHWjg fu1fxLz6uP9taOWfmVPL9W+s7wr6YL/0L4npb7EvoylpzEO7md/LIWx0/5RhhOJjsjxb 7pHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZB8uaH47tlHMfa+ir70KGeuEZgNNNt12CRoSphH8LbE=; b=GbTO5dNsxOMxCjQq4UmEjjv5hhYpyLIlJLy1pO+HweiLCD3epawkBvEFfGRMudc2ZW ilBSzaLpXFiMgWCeh6p0V72iHNf8OgKpYCGq+XMDOkl/B/VyvuYN8lWm4XepZ54GFoQi 3fyQs2jfNDOFtplJTMD7RamQCrHcnzKZ04Iv+B9U3aWNiRIMIQZKn0aCX/TnMhjdvD00 yW7HgBOXRfVcvPWe9vYSmVLcd3EcyWcWcv54y9wYc0D/IX+lBXwiwP8NQLg3B8oro4GQ lS2WFxHcHPZcyMx2mXiOLDL1Ux48Tn1KaH6GJm454oP/IWNnuRhq8LGXRI7UiQu8x4vb Z6Lg==
X-Gm-Message-State: ALyK8tKCflHGQEEwNeTwP9VSGTFkeV9aBl9ePfMa2dEKymQ/3DTwAHS9o5qhvKwp68zygpca2RoDwy9RDtCoew==
X-Received: by 10.129.161.129 with SMTP id y123mr29949222ywg.214.1468941902970; Tue, 19 Jul 2016 08:25:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.152.13 with HTTP; Tue, 19 Jul 2016 08:24:23 -0700 (PDT)
In-Reply-To: <013101d1e1cc$253eddb0$6fbc9910$@delignat-lavaud.fr>
References: <20160719134626.GA14259@LK-Perkele-V2.elisa-laajakaista.fi> <013101d1e1cc$253eddb0$6fbc9910$@delignat-lavaud.fr>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 19 Jul 2016 17:24:23 +0200
Message-ID: <CABcZeBMAAThwMaFxY4FoPY5p8Pfd8ESRGO11n7-7WqdNAoi-gw@mail.gmail.com>
To: Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr>
Content-Type: multipart/alternative; boundary=001a114f8db252b0ca0537feb068
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/aaGUkKe57ngQkd9aAYUpD1rX4Lk>
Cc: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>, Markulf Kohlweiss <markulf@microsoft.com>, "tls@ietf.org" <tls@ietf.org>
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:40:18 -0000

On Tue, Jul 19, 2016 at 4:45 PM, Antoine Delignat-Lavaud <
antoine@delignat-lavaud.fr>; wrote:

> Dear all,
>
> Here is an extended summary of the early Finished / resumption context
> discussion at the WG.
>
>
Thanks for writing this up!



> 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.
>

Note that this form of PSK + server signature isn't a mode we currently
specify
in TLS 1.3  However, given that the negotiation changes we discussed today
would in fact enable it, it seems like that would be something that's good
to fix
now.


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.
>

I think this is the best option at this point.

-Ekr


> 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
>
>