[TLS] 0-RTT & resumption

Dave Garrett <davemgarrett@gmail.com> Sat, 25 July 2015 18:53 UTC

Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id B58EF1A8956 for <tls@ietfa.amsl.com>; Sat, 25 Jul 2015 11:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nPbNEDu2oSAI for <tls@ietfa.amsl.com>; Sat, 25 Jul 2015 11:53:20 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 990451A8944 for <tls@ietf.org>; Sat, 25 Jul 2015 11:53:20 -0700 (PDT)
Received: by qkdv3 with SMTP id v3so27777090qkd.3 for <tls@ietf.org>; Sat, 25 Jul 2015 11:53:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=rPFkkVbBYC0Ix142cqR1UB35JCyBqJBMKRlZo4TYbhA=; b=L2QDcozWfMlm1ShJVjHaaFIoYGtx4eNUT/MjmJYQlyLuEZuN6ruLe7ZyiYW8kIwsYC Bf48haWC9LPU2JawIGjdN94B9SZxIfHba3xqCDEXMR8hOW5vSNk5MZ0HpnXmmWFhPk/I KdD+QeRsVo8B/3QMf9fLfP/EHnKD5L0MpNtzVQP+4F6lBMqRecVO/9w6G2Y7DdPM2Al5 97z4vIFDs40EmlS5SAFonRHAbqbWOGNKIshcIHInE3kcf2fIhnLMbmopOD5ov49vQ9jX ZCLRljlBnEpnBXEuuRclDxz9pUyrOmyd1/BZAH67smewLJFJpWztwDorrvGLaZLwc6kX JVmg==
X-Received: by with SMTP id d40mr29107333qkh.15.1437850399917; Sat, 25 Jul 2015 11:53:19 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. []) by smtp.gmail.com with ESMTPSA id o65sm6064979qge.34.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 25 Jul 2015 11:53:19 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>, Eric Rescorla <ekr@rtfm.com>
Date: Sat, 25 Jul 2015 14:53:17 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201507251453.18237.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/4t9_dtnhvb8R1VluhRSDl0O-MCE>
Subject: [TLS] 0-RTT & resumption
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: Sat, 25 Jul 2015 18:53:22 -0000

I'm pretty sure some/all of this was likely mentioned elsewhere, but I don't see any discussion on-list. (it was mentioned in part of the IETF 93 recording I watched as this whole topic needing to go to the list, as well) There's also related TODOs in the draft on this topic. Here's a start to this discussion.

Basically, there's two modes with similar use-cases in TLS 1.3 now: 0-RTT connections using the known configuration extension & PSK-based session resumption. I don't think their roles are well defined yet.

1) There is no 0-RTT resumption. The point of resumption is to get back into the session quick, but it's arguably slower than not doing it, currently.

0-RTT can do first flight (repeatable) requests:
but PSK-based resumption needs 1-RTT:

2) There's not yet specifics on what cipher suite to use for PSK-based resumption. I don't see a point in doing PSK-based resumption with anything other than plain PSK, with no PFS (no (EC)DHE). If you're willing to do the extra work for DH, just go straight to normal 0-RTT to get more benefit/flexibility with a similar amount of work. The goal is really to get forward secrecy on the session, not necessarily every single connection within it. (not that it wouldn't be nice) As long as the resumption is within a reasonably short window (e.g. few minutes), not doing another DH is fine. After this window, normal 0-RTT should be the preferred route.

3) Just to state the obvious: If a client is going to do PSK resumption with a non-PFS suite, it needs to offer a non-PFS suite. Even if it's not really going to be negotiated for anything else, I don't really like the feel of this. I think it'd also be cleaner if the offered suites didn't have to change for resumption. One idea would be to rename the groups extension, again, to "supported_key_shares" and mark point 0 (or some other if we want to leave 0) as PSK-resumption, specifically. (_not_ general PSK) A resumption PSK offer could then be listed in the ClientKeyShare like any other, and negotiation of it could side-step the need to pick a new cipher. Mixing it in with regular PSK complicates things a bit and has an expectation of needing to offer a PSK suite with the PSK extension. In this case, it'd just be the previously used suite. 0-RTT becomes a little more straightforward: give both short-term resumption via PSK and mid-term semi-static secret 0-RTT clear expiration dates, then the first flight data is just encrypted using whatever is still valid. Worst case scenario is the server ditched the session early and it falls back to 1-RTT. (double-encrypting early data might work, but would be ugly) This sort of re-separates PSK & resumption a little bit, though the handling is still similar.

4) Related issue: maybe define a generic KeyShare struct (group+key_exchange), simplify the few spots to use these, then allow ServerConfiguration to offer a vector of KeyShares? Alternatively, just have one KeyShare in there and offer a vector of ServerConfiguration in the message so each has an expiration date. If we want the possibility of ServerConfiguration being obtainable through alternate means, then it might help for a server to be able to offer two keys with different curves to make support easier to offer. (e.g. P-256 & Curve25519, as we may be transitioning this way for a bit; could be ECC & PQ of some kind, in the future) This might make constructing a 0-RTT first-connect system a little easier.

Not a solid proposal, really; just some discussion on the topic.