[TLS] Proposal: Simplified Key Schedule
Eric Rescorla <ekr@rtfm.com> Thu, 18 February 2016 21:06 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8A51A0369 for <tls@ietfa.amsl.com>; Thu, 18 Feb 2016 13:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Level:
X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] autolearn=no
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 dnN-n7txV8Pg for <tls@ietfa.amsl.com>; Thu, 18 Feb 2016 13:06:05 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 033A21A90DB for <tls@ietf.org>; Thu, 18 Feb 2016 13:06:05 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id h129so51478960ywb.1 for <tls@ietf.org>; Thu, 18 Feb 2016 13:06:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=PqJ7sytmQ5ElsUh0mM9YQ+U+zNcZubstlq7yQli6eRc=; b=lo3x+vCULIV8fHnESAqSVg0Yd2IfBcn7UqaMKzDISjdx5DDl92hTY7/bz82W7qWD+x 11vdesocu5fXfo+1l92Xvvrr7I5ybJb6XrUL2H4zPzPiNP8bx1ZLjBGvHNAwtOuU9Eni ls3V599/m90ixfnk+QZ8BPME0tUNSehsCWDoc5K+Yr0/BAszGgWP70bs23iTmuIMzICX 0KDqfeIVR3hRLzVhEwjj0th+0ICxwWI1OQeOpF3clTx0ihztduC+ApW6ReqwRYDB4uY4 58ZPeZg+aVPEydKW3P17BWhyrmGi/Z1n2TFNzx68jAiOXwh3rr7tmMPUY1cDVduK1g2w LAzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=PqJ7sytmQ5ElsUh0mM9YQ+U+zNcZubstlq7yQli6eRc=; b=L713j3DzDh0lQGYZ6/H1TV+Y7AJYrxbTuRKQAr+4f8JymHClGR/ynuXn3fKgvqHAau vSLetaWr/vzTz8Mq6C0A4LNAvtU7t5wFJ50JECcG0UJ75rAA/WUokHPVVH3cKJxfRHxD Zvdnd+0FkJjk3ayGyqvf9PxU3YPff/GgLVF/HmKs/R8ptTTs9v0x5BnONtKmJl/0Nrx6 gYGbEdwR51DbZkAlWIwSLZ9NH5vte+E5++EzvveusGPwwcdCAFNtEZkgF7Cc4e+sHS8e PkRxB1xIndlLTQ1S1DLp4WdcB5e8F02KZdNRqI6hkM5NgxYdZSXfuJhbH1Ga120jBm3S VFSQ==
X-Gm-Message-State: AG10YOSOiCxfvniFSEAIRt47Bny37BViP2nh0XpH/SxYBLnKrOH+WuU3dFmIywj1HHgyfnVwhMm4h9A0NMnRCA==
X-Received: by 10.129.46.15 with SMTP id u15mr5532657ywu.129.1455829564246; Thu, 18 Feb 2016 13:06:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.5 with HTTP; Thu, 18 Feb 2016 13:05:24 -0800 (PST)
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 18 Feb 2016 14:05:24 -0700
Message-ID: <CABcZeBMpvwjta9C++bE5s152HzjyQe75yjhByqHGdRF7AkRvRA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11414df0081211052c11bc90"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/uUbeVDQwJuZO_bYhOWJRvlNlNtg>
Subject: [TLS] Proposal: Simplified Key Schedule
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 18 Feb 2016 21:06:12 -0000
Hi folks, TL;DR. Let's simplify the key schedule. DETAILS This is the second in a series of proposed simplifications to TLS 1.3 based on implementation experience and analysis once the protocol starts to harden. The following suggestion comes out of conversations with Richard Barnes, Karthik Bhargavan, Antoine Delignat-Lavaud, Cedric Fournet, Markus Kohlweiss, Martin Thomson, Santiago Zanella and others. The current key schedule is elegant but it is actually more than we need in that it allows SS to be known either before or after ES. If we assume (as is always true in the current TLS 1.3 modes) that SS is known before or at the same time as ES, then we can design a simpler scheme which looks more like a ladder. Something like: 0 | SS -> HKDF [ClientHello + Context] | \ | \ v v X1 0-RTT Traffic Keys * | | v ES -> HKDF [ClientHello, ServerHello] | \ | \ v v X2 1-RTT Traffic Keys * | | v 0 -> HKDF [ClientHello...ClientFinished] | | v RMS, EMS As should be apparent, this key schedule is well-suited to the simplified key change schedule in my previous message. Note 1: It might be attractive to not even bother with the first stage if you aren't doing 0-RTT. It's not necessary then. However, this is just an optimization. Also, if you don't want to extract an RMS or an EMS you can skip the last stage (this is compatible). Note 2: The IKM for the final HKDF is 0, but in principle we could use it to add some sort of new keying material, for instance g^xs if we were using static DH certificates (see below). In line with Hugo's message earlier today, the major argument against this design is that it is more oriented towards a signature-based system, which TLS 1.3 is today, than towards a DH certificate-based system. To elaborate on this a bit, in a DH certificate-based system, the server authenticates by proving knowledge of g^xs (and hence s). In the current TLS 1.3 design you can do this trivially by replacing the signature in the server CertificateVerify with a MAC over the transcript (using g^xs as the key) [again, analysis needed.] This is straightforward and doesn't require rearchitecting the protocol really at all. However, this (as with the current signature-based mode) does not provide confidentiality of the connection if y is later revealed. As Hugo has noted several times, if you mix both g^xy and g^xs into the traffic keys, then you are protected if either y or s is leaked, which gives you somewhat stronger security properties with a DH cetificate The current key schedule accommodates that by allowing for SS to come before *or* after ES, but the simplified schedule does not quite so easily. With that said, TLS 1.3 doesn’t support *any* pure static DH design now and will do so even less well if we remove the key change as discussed above. There are at least three ways forward to incorporate them in future: - Just do as I suggest above. - Define a new DH cipher suite that adds an additional key change. This would allow us only to have the key change complexity in that mode. - Replace the 0 in the above schedule with g^xs and then define that the key for KeyUpdate is actually coming out of the final HKDF. Any of those seem like they wouldn’t be too hard to do, if and when we start having a lot of demand for DH certificates. Please discuss. -Ekr * Note that as I indicated in my previous message, it is possible to generate multiple sets of keys at the same stage, if that is necessary to handle the analysis concerns.
- [TLS] Proposal: Simplified Key Schedule Eric Rescorla
- Re: [TLS] Proposal: Simplified Key Schedule Hugo Krawczyk
- Re: [TLS] Proposal: Simplified Key Schedule Karthikeyan Bhargavan
- Re: [TLS] Proposal: Simplified Key Schedule Eric Rescorla
- Re: [TLS] Proposal: Simplified Key Schedule Ilari Liusvaara
- Re: [TLS] Proposal: Simplified Key Schedule Hugo Krawczyk