Re: [TLS] Simple, secure 0-RTT for the masses

Bill Cox <waywardgeek@google.com> Tue, 15 March 2016 21:13 UTC

Return-Path: <waywardgeek@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B466C12DD90 for <tls@ietfa.amsl.com>; Tue, 15 Mar 2016 14:13:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 XLZAt_lr5Pir for <tls@ietfa.amsl.com>; Tue, 15 Mar 2016 14:13:10 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 5E08312DAFD for <TLS@ietf.org>; Tue, 15 Mar 2016 14:13:10 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id m184so40233205iof.1 for <TLS@ietf.org>; Tue, 15 Mar 2016 14:13:10 -0700 (PDT)
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; bh=EgIUTGQEgzL9/roL0RNTkLycyIZLU5iPWY256RcBhEk=; b=HlGZWf3IbS7UNyYwH5r/2YHqztqHJ0rDNjGFXll4AhcnA4n9NzL25QfX/7Zvwq5bh1 +V/UHr7EDDaO3I7DqXkCHoLwQAkl0NpOQBfjSe/j9jb2IpMqG0Z0ianI1gNkgkTGDLb/ ZkYa/2u++HoL+A0uAf7obaesxF9wy18PTD+Ozwd5PDpypPYqLUT/Cu++mZmkJyHrFYp6 I29nxMEH7lZs9upFX5GRiguAzjl/X/tXREz4DV4HUyjyiKHrtxqyi8WTTXeTdCDLdhy1 q/I/hWoelhqJ5pbTx5N7I1OAQlTZdjVDmB0TjyutdYZ5V1DRrkUo92ICk216AImGSkGK ZqSw==
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; bh=EgIUTGQEgzL9/roL0RNTkLycyIZLU5iPWY256RcBhEk=; b=KhsE1wBe08ue5gbw/A2dwm6Q2mVIXvR6aiqOvDcBl/Glq4U05kLHN3XWM31Z9ZhPy6 Zu2vl9iH58pF44sea81Kop69V68/F+3XR91ih4TawgoXYn98nEl9K+AJ2IgPI/KNImb6 enqQBRCshUuRn01cbM5crCEJx11sDNuVxALd72bS2JYNR6cU6CSc1arOi1JTLJE6bs5U deDznNs2grahuEiWAv1amdLxx4sD9fXsRVn+27eknAicpAuQDSrUlD4KilnWA4YIJdbQ H27ef/L0CspeRDcGDl8FS5Z6SeA/9l9QlSBdDnz+P+95RN1HE4IcfcGaHKNUojELdztf RN0w==
X-Gm-Message-State: AD7BkJKY3MA0T+yH/H9671hrl1jD/cOgqzKmowFHwwJXPNINOnbIMuL5VvF7laKE2B1hPxpyI6qfBSoJHFpEYryB
MIME-Version: 1.0
X-Received: by 10.107.8.30 with SMTP id 30mr910614ioi.60.1458076389623; Tue, 15 Mar 2016 14:13:09 -0700 (PDT)
Received: by 10.107.137.80 with HTTP; Tue, 15 Mar 2016 14:13:09 -0700 (PDT)
In-Reply-To: <CAH9QtQGdZ9=XG-Qc5G6amM1pOnBse5jZndL0kExxArWXoQbhsQ@mail.gmail.com>
References: <CAH9QtQGdZ9=XG-Qc5G6amM1pOnBse5jZndL0kExxArWXoQbhsQ@mail.gmail.com>
Date: Tue, 15 Mar 2016 14:13:09 -0700
Message-ID: <CAH9QtQGfqv7SxubWx9F6yz2g5s8=7CJqae3+3iANG-hBokRvHA@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: "tls@ietf.org" <TLS@ietf.org>
Content-Type: multipart/alternative; boundary=001a113fb716428621052e1cdd52
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/NXkFHwXLliRbm3OsWtOQSHTME-I>
Subject: Re: [TLS] Simple, secure 0-RTT for the masses
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 15 Mar 2016 21:13:11 -0000

Second attempt, since Colm already broke my first attempt:

It uses a traditional server-side session-cache in addition to the current
client-side session-cache in TLS 1.3, and also a server-side ticket
encryption key.  The protocol looks like this:

During the initial 1-RTT handshake:
- create an encrypted ticket containing only the session ID and a
"resumption count" set to 0
- send the ticket to the client

During a 0-RTT resumption handshake:
- Decrypt the tikcet and get the session ID from the ticket, check for a
cache hit, and drop to 1-RTT if not found
- compare the resumption counts in the session state and ticket, and fall
back to 1-RTT if they do not match
- increment the resumption count in the ticket and session state
- send the updated ticket to the client

There is little PFS here.  Some can be had by flushing stale cache entries
and rotating the ticket encryption key often.

Are there any holes in this scheme?

Bill