Re: [TLS] Forward secrecy with resumption, and 0-RTT security

Bill Cox <waywardgeek@google.com> Sun, 06 December 2015 22:55 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 46C8D1B34E6 for <tls@ietfa.amsl.com>; Sun, 6 Dec 2015 14:55:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IfIyhyjsDNpn for <tls@ietfa.amsl.com>; Sun, 6 Dec 2015 14:55:21 -0800 (PST)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 1F1FD1B34E3 for <TLS@ietf.org>; Sun, 6 Dec 2015 14:55:21 -0800 (PST)
Received: by igbxm8 with SMTP id xm8so71102367igb.1 for <TLS@ietf.org>; Sun, 06 Dec 2015 14:55:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XYry1+LjARvS/H4reHt/Lo3B62UQdgQEoJoV4v6hl+c=; b=Hcsl8q79NtvJf5utNKRX2Fac1R0mogTS4cPqYoQ9LNK1lHzb1p9VZZjS2F96YNneUC GE1GkYuLdGunGap5UE/p1dw8nIMCDHm7z0sSPI9ta5DfOYIAJO4xWv7aN857KxnjwqxN KZgwXDMsvYgW5iteJjn8C7jrzZZjcIfvqWREX1KlIz9FZXO9pGpuUKUPKAMZrDzU4Qba zf5AKEFoIkp8HNEIuui7x9KA8fQoOhcsBHCqTY54HxkNC7vbMOw/U56unqBJMrc25Yn3 AnMNupLmPQ7frsUMc5sprFaMB7Dj+7q7sW+En1RdfuZx5GCZV9bDKjW80qBnre/CNPPZ Ej/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XYry1+LjARvS/H4reHt/Lo3B62UQdgQEoJoV4v6hl+c=; b=UiqF86o49Od41wG5KmIj+080aU6HsoHmhY5+B9H4s1GgUzu79+2IxPWz4X9EN/YdCV dn39UPNgtJmnY0k1B9n6HsdGReoGKPQ3xJgS8NgAEEx4Y5w+Xi4+8R/uf4itqVLO/9X/ tJriJekvAShdO+2d9D7M6RFY06uLhLEBGG1s3nPRwYkA1+s1rem1p6EnPXDq0+6zFOaJ 5fta72ePg/xc6xTIh8JP4/vC4ZvulpQ0frFMFaLWmLYjQYxeEjOPJo4mZqYY8m27ifZS 87k/0+h0UBlevu6GYMxgqO4YIDmTwDP63L7wsG15VeS7/VjJk+ojdIoYJAbNTtVnikkS igVg==
X-Gm-Message-State: ALoCoQlF4VQl5Cwz0z43Y/Qan+Gw1USuPYVc/7pT/w88R2M9dZYXKNNjf5q5bt1foC9EoM4y9wT2
MIME-Version: 1.0
X-Received: by 10.50.61.37 with SMTP id m5mr14295724igr.4.1449442520405; Sun, 06 Dec 2015 14:55:20 -0800 (PST)
Received: by 10.107.173.15 with HTTP; Sun, 6 Dec 2015 14:55:20 -0800 (PST)
In-Reply-To: <CAH9QtQFzAODYNLsWA9u==bG5ksvatRdbgjaxhMWhZ3NQEG9yqQ@mail.gmail.com>
References: <CAH9QtQEMcVkZAwOS5xCWFCw0uBvQd+Q+Wsj7fXtm3_p6XHk_pA@mail.gmail.com> <CABcZeBPLtB3YZsEpm9+xhm9p2H7q__68JS8Vx=Lw1Ae-5e94Kg@mail.gmail.com> <CAH9QtQHaXNJPyUJ_2GaCAp4J2rhs84juwBqjV=RZ+rOe35RAFw@mail.gmail.com> <CABcZeBMNDD5JMSY+4w=mvDFMW9VcdLtfNs0C71zV6g-Yjz=o9Q@mail.gmail.com> <CAH9QtQFzAODYNLsWA9u==bG5ksvatRdbgjaxhMWhZ3NQEG9yqQ@mail.gmail.com>
Date: Sun, 6 Dec 2015 14:55:20 -0800
Message-ID: <CAH9QtQEmeT7zP=aCr1oCFZoASDg561TLCuxOCADo5o_bbkS_bw@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=001a1135f3048d71dd052642a205
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/udkimDztqxCBc_n23XVljpW8vVU>
Cc: "tls@ietf.org" <TLS@ietf.org>
Subject: Re: [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 22:55:22 -0000

Just how strict do we want to be with forward secrecy?  The choices I see
are:

1) Avoid 0-RTT connections, and do only 1-RTT connections when we want
strict forward secrecy and strong client authentication
2) Keep server-side state for decrypting each ticket, and issue new tickets
on each connection, while avoiding 0-RTT replay to the same data center.
3) Give up on first flight forward secrecy, as well as client
authentication for first flight data.

If tickets are reused for multiple 0-RTT resumptions, then the earlier
connections can be decrypted using whatever state the server keeps to
decrypt later connections.

I think option 1 simple and secure, but is too slow.  The choice between 2)
and 3) is a security vs cost and complexity trade-off.

No new functionality is required to implement 1, 2, or 3, I think.  It can
be up to the implementation and application.  Is it worth spelling out in
the spec the gory details?

I'm trying out some language for implementing 2, and the downsides for 1
and 3.  Not sure if it belongs...

Bill