[TLS] Forward secrecy with resumption, and 0-RTT security
Bill Cox <waywardgeek@google.com> Sun, 06 December 2015 14:50 UTC
Return-Path: <waywardgeek@google.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 94F731A8715 for <tls@ietfa.amsl.com>; Sun, 6 Dec 2015 06:50:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.511
X-Spam-Level:
X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 x9_Z2HamdugM for <tls@ietfa.amsl.com>; Sun, 6 Dec 2015 06:50:05 -0800 (PST)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 395171A1BF1 for <TLS@ietf.org>; Sun, 6 Dec 2015 06:50:05 -0800 (PST)
Received: by ioc74 with SMTP id 74so158574851ioc.2 for <TLS@ietf.org>; Sun, 06 Dec 2015 06:50:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YWMxBoCX1lKh2EALyxkuI0/L5EapIh7eE97ykmQdDmU=; b=JJmB+F28BdtOA1Lq8cCeT6sl0nxVIwmzY+j4JGBd4TARfDQSkFPu1p8K9aeM0Z4X4B DuJR8X/qJkt/LoOwTxG71/sBGycXp2a6TYXZ576ytQJ/EgCPcaIwBKu3LdE/PsWKycjv TAnLi2H0olDc6ocCrcmIpDhSo23/vH3d9XZxNgZXjUWu8JqYbYBSV1oS1ixJS5H6hE0A tSWVRXysgOWDqqzpYCUF4k/Cl2tAn9FiUtZt2IYYuEveyE+3hykih3qxTH9d4tGiwnP/ jq+w/8VRgMp63IVi9b9oOJnPr7hOlj5xoZ7TVBmnR9qkqwC/RC9ZceDW2+JdgaAknZEt Wo0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=YWMxBoCX1lKh2EALyxkuI0/L5EapIh7eE97ykmQdDmU=; b=jCnJrlcW9UZU6J93IFcj6zDegwaPmbSLOYlVgihgvtbOCUS30Mw3UgSvVsDpllyfNC Jck+whQWbt6JYhXs78GrxJxcxfu+0Lzcd9xkKNQ3kOhKJuZMKbqeAoi77/qb45Is9+Wq C5DgN4bSiJgKYnUFX/QGhOHO5iplJA7+2CeONBXTx6nsbRmfFsZNz+IyU1lAuOXVPcvv I2HUjHpoaD//dPVJSqxjxi1Ew5Kp41371h0L30usBPVdZnOvy0bPRb0Mel6s+N1FlLgm uB7Ir82TuXAziFcwx6TXX8T0str+oFL9gUeILoLI0xzH1d9TYqy3NgAB0Z8HdpRRLy9n EevA==
X-Gm-Message-State: ALoCoQmhFGHtFizut0ei9ygE+OQpnkjnplWmJf80izDSuDb4BrJT9N2rZqWTZtEeXb04medRLotp
MIME-Version: 1.0
X-Received: by 10.107.152.133 with SMTP id a127mr22971683ioe.60.1449413404375; Sun, 06 Dec 2015 06:50:04 -0800 (PST)
Received: by 10.107.173.15 with HTTP; Sun, 6 Dec 2015 06:50:04 -0800 (PST)
Date: Sun, 06 Dec 2015 06:50:04 -0800
Message-ID: <CAH9QtQEMcVkZAwOS5xCWFCw0uBvQd+Q+Wsj7fXtm3_p6XHk_pA@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: "tls@ietf.org" <TLS@ietf.org>
Content-Type: multipart/alternative; boundary="001a1140e69e1a1fa505263bdb0e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/8_PFlpGltz6_974FiqViTgPakM8>
Subject: [TLS] Forward secrecy with resumption, and 0-RTT security
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: Sun, 06 Dec 2015 14:50:07 -0000
AFAIK, there has never been a session resumed with forward secrecy. Is this correct? In the past, there were two cases: resumption using session IDs, and resumption with session tickets. Using session IDs loses forward secrecy, because the server always has session keys in a session cache, which could be used to decrypt the prior sessions. Using tickets did not work either, because the server always kept a ticket decryption key which could be used to decrypt all resumed sessions since the key was last rotated. My first question is: Do we care? The original definition of forward secrecy seemed to mean forward secrecy for all sessions older than the key rotation interval. This is what Twitter had when claiming support for forward secrecy. Do I understand this correctly? However, the new definition we seem to be using now is that no past session can be decrypted using server-side state that persists after the connection ends. Under this definition, AFAIK, there has never been a resumable session with forward secrecy. Is this definition taking forward secrecy too far? To have forward secrecy under the strict definition using the new PSK scheme, we need to use what the new name implies: pre _shared_ keys. The new name implies that the server remembers a unique shared key for the connection, which is server-side state per resumable connection. If we only store the PSK in the ticket, and go stateless on the server, then the server-side ticket decryption key again defeats strict forward secrecy. With a remembered server-side pre-shared secret, we can have a 0-RTT resume with strict forward secrecy. Is this already implied in the spec? If so, the spec could be improved, by stating this explicitly. However, the current statement that 0-RTT does not provide forward secrecy seems to be wrong in the case that we resume a 0-RTT connections with a server-remembered PSK. To have strict forward secrecy, given that the server already has to have server-side state (the pre-shared key), I find the old session ID scheme more palatable than the new tickets. The main point of session tickets was to eliminate the server-side session cache, wasn't it? I think the current spec does not describe well enough how to implement secure 0-RTT infrastructure. Instead, it seems to recommend against using 0-RTT, with a pretty dire warning about the insecurity of 0-RTT. I think that nearly the entire world will switch to 0-RTT, regardless of security limitations and warnings. Companies won’t be able to resist the improved connection time. IMO, the spec should describe how to address the security issues with 0-RTT, rather than just warning about security issues. So, here are my dumb thoughts about practical 0-RTT security infrastructure... One way is to bind resumption to orbits, by having only the orbit that issues a PSK remember the secret key. Something like this is needed in any case to provide 0-RTT replay protection. Without at least orbit-based replay protection, I think it does not make sense to allow a ClientVerify in a 0-RTT connection. There was a TODO in the last version I read asking what the client would sign in a 0-RTT ClientVerify. If orbit-based replay protection is in place using PSKs, then signing anything that identifies what PSK to use is enough. However, the handshake has to somehow be bound to the orbit to prevent the signature from being replayed in a MitM attack. Having a ticket that can only be decrypted using the orbit-specific ticket decryption key would work. Using a source address token bound to the orbit would also work. Signing the server Finish is not required to insure the signature will only be accepted once. There are two parts to a proof-of-possession: uniqueness and freshness. Uniqueness can be had using orbit-bound PSKs. Insuring freshness is harder. This could be done by adding timestamps to the material signed. With this, we would not get a complete proof of possession, because an attacker can attack the client's clock, unlike a normal proof of possession. However, if steps are taken to secure clocks, which is needed for TLS in any case, then we can get what I think of as "compelling evidence" of possession, which might be good enough. I think I've partially covered all three security concerns listed for 0-RTT connections: forward secrecy, replay protection, and client certs. The limitations seem to be: - 0-RTT resumption using PSK can address all 3, but not 0-RTT connections - Strict forward secrecy requires server-side state, so why are we using tickets? - Replay protection based on orbits is only partial protection - ClientVerify can only provide “compelling evidence”, rather than proof of possession It concerns me that the TLS 1.3 spec seems to say "Don't use 0-RTT! It's not secure!" when it is clear that the world will go in that direction. I would feel a lot better if the spec had more discussion about how to do 0-RTT securely. Thoughts? Bill
- [TLS] Forward secrecy with resumption, and 0-RTT … Bill Cox
- Re: [TLS] Forward secrecy with resumption, and 0-… Eric Rescorla
- Re: [TLS] Forward secrecy with resumption, and 0-… Bill Cox
- Re: [TLS] Forward secrecy with resumption, and 0-… Eric Rescorla
- Re: [TLS] Forward secrecy with resumption, and 0-… Bill Cox
- Re: [TLS] Forward secrecy with resumption, and 0-… Bill Cox
- Re: [TLS] Forward secrecy with resumption, and 0-… Tony Arcieri
- Re: [TLS] Forward secrecy with resumption, and 0-… Bill Cox
- Re: [TLS] Forward secrecy with resumption, and 0-… Benjamin Kaduk