Re: [TLS] Fate of resumption

Erik Nygren <erik+ietf@nygren.org> Sun, 19 October 2014 15:44 UTC

Return-Path: <nygren@gmail.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 C6D9D1A1B4E for <tls@ietfa.amsl.com>; Sun, 19 Oct 2014 08:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 IkWL4d8dPVz6 for <tls@ietfa.amsl.com>; Sun, 19 Oct 2014 08:43:59 -0700 (PDT)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5E21A1B4D for <tls@ietf.org>; Sun, 19 Oct 2014 08:43:59 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id lf12so2544826vcb.3 for <tls@ietf.org>; Sun, 19 Oct 2014 08:43:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bUOAP8viiNwI5f9Y2aXQeIoy8bgtZ/qsm4SqvQH39C0=; b=fXIQZ8AXVUn+q/N0eRkp88sMFTPoRRDea0vP+hISINJ0cJldxrGJICmjzD0WLUsumc f/xZCn+CYxkHuea/Kui8ZxBDRkD0uvJNJoIeOh2J29SFmPf2Nay68slRsQWrE4G/lUeB y6JkbCIKgvPLHbO15cFsJD/DJHYLOyT4sIFVK6vfo5hFtL+vlkUCp+yOOKNaEi1hye5q qI7aIlXrNosztLrOD++A7w+bSUFTxZdbv5UGtuCN68OLxPq9UBIid+2u7+v12jkKm7Ol HPS4P+wusOb6fvonDkHSmhFK4dweeuzr8guBfcYJ2Yw3mMEWIG9bltfDjRf1Iwwhyph3 Lkyg==
MIME-Version: 1.0
X-Received: by 10.220.195.196 with SMTP id ed4mr600853vcb.65.1413733438461; Sun, 19 Oct 2014 08:43:58 -0700 (PDT)
Sender: nygren@gmail.com
Received: by 10.220.12.11 with HTTP; Sun, 19 Oct 2014 08:43:58 -0700 (PDT)
In-Reply-To: <CABcZeBP4=aXbQSFAhh4EenwRiTrv2LP=r50VeULm4f_0RR4swA@mail.gmail.com>
References: <CABcZeBP4=aXbQSFAhh4EenwRiTrv2LP=r50VeULm4f_0RR4swA@mail.gmail.com>
Date: Sun, 19 Oct 2014 11:43:58 -0400
X-Google-Sender-Auth: 0YJ3WF_DCATIkUkBvLLfML7KO58
Message-ID: <CAKC-DJhHKWPSj9pOvDOuvtteD3VtnQDHBtckEFadasJuZG5Mog@mail.gmail.com>
From: Erik Nygren <erik+ietf@nygren.org>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="001a11c1c324681d7a0505c877d6"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V-rezzMj-DBMZO6aulDzcG5gAL4
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Fate of 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: <http://www.ietf.org/mail-archive/web/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, 19 Oct 2014 15:44:01 -0000

On Sat, Oct 18, 2014 at 12:16 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> I wanted to get the discussion going on whether we need resumption [0] or
> not
> for TLS 1.3. This may be a quick discussion as I suspect the answer is
> yes, but I figure we should decide it rather than just assuming it.
>

+1 for leaving in resumption for TLS 1.3, for the reasons mentioned.

Resumption is another part of the "istlsfastyet" story that helps in selling
people on making TLS more ubiquitous, both from a performance
and cost perspective.  Dropping it at this point might harm adoption
of both TLS 1.3 as well as momentum towards TLS in general.

(Some of the other discussions on this topic focused on best
practices around session ticket key management.  If resumption
is going to stick around, then ideally there should be a BCP or similar
on sane implementation practices that do as little harm to forward secrecy
as possible.)

One other thing we may wish to consider is the relative safety
and complexity and interactions of 0RTT vs Resumption for various scenarios,
such as against replay attacks (when nonces are available and
when they aren't available).

       Erik