Re: [TLS] 0-RTT & resumption

Eric Rescorla <> Sat, 25 July 2015 19:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6C5341A903A for <>; Sat, 25 Jul 2015 12:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yq-Dcxr7mvuH for <>; Sat, 25 Jul 2015 12:08:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D658A1A1A3B for <>; Sat, 25 Jul 2015 12:08:29 -0700 (PDT)
Received: by wicgb10 with SMTP id gb10so64340304wic.1 for <>; Sat, 25 Jul 2015 12:08:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7Mjx4i9V83q49zQofB2fACVk0mecW50auiSKOgncITg=; b=meWl9BuMRTB/t7XJaWzJrmr+/FXNRQUO8go9uVcQ5olbHzPpMtlYfGs8ffI+9eYcqe fNFwTah0LXJ/Zjo6WIguR8rSvJ+DZ4Cj2XPi/kOCSk4nFj8bPsSYMsW5TqAhlRLW49hq jk2gBId46GOp/AZ7K7yP2r+sWO/px+EUn3eoOwCsb4bmnCIffNtYCLVyzhXl8wSsgM3W rrEfVJxxq83j9CPt4j5f2OAV+Qt663KCMeAV9qmkWRXkDMyxWHOFqibdXmpQEf2N7mfE iefCOHTKxtqwoHq0ryJAQFReKWUYNgM+GP80ITDSrUOqUOXMMBPnI1QYoGbAihfNEt7t gIyg==
X-Gm-Message-State: ALoCoQmN4uIo8nlSIBlPS7ZJhV94vVse2E/iNAwBe7LqAigJcIyn2mzG+Qy7RuA4rGd5QSMe8l2e
X-Received: by with SMTP id o20mr8641249wiv.31.1437851308624; Sat, 25 Jul 2015 12:08:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 25 Jul 2015 12:07:49 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Sat, 25 Jul 2015 21:07:49 +0200
Message-ID: <>
To: Dave Garrett <>
Content-Type: multipart/alternative; boundary="f46d0435c06a7da583051bb7d864"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] 0-RTT & resumption
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 25 Jul 2015 19:08:32 -0000

On Sat, Jul 25, 2015 at 8:53 PM, Dave Garrett <>

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

We agreed on how to do this in Prague. The sticking point was establishing
the cipher suite. I have WIP text on my machine for both of these which I
will be
sending early next week, once I get enough sleep to be able to clean it up,
so I'd ask people to sit tight till then.

2) There's not yet specifics on what cipher suite to use for PSK-based
> resumption.

The consensus in Prague was that you should have to use a matching symmetric
cipher suite.

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.

I don't think this is correct. The reason is that resumption also resumes
the client's
authentication state, and client authentication often involves user
interaction, which
is undesirable from the site's perspective. So, it's actually quite
attractive to do
resumption with (EC)DHE. It's also significantly faster if you have an RSA

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

Yeah, we discussed this internally, but I think it's clumsy. I'd rather
just offer two separate
cipher suites.