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

Bill Cox <waywardgeek@google.com> Wed, 16 March 2016 16:12 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 A96CB12D75D for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 09:12:53 -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 suAuecHo1eXv for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 09:12:51 -0700 (PDT)
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 CAC9912D626 for <TLS@ietf.org>; Wed, 16 Mar 2016 09:12:51 -0700 (PDT)
Received: by mail-ig0-x232.google.com with SMTP id ig19so48360886igb.1 for <TLS@ietf.org>; Wed, 16 Mar 2016 09:12:51 -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 :cc; bh=9+Qrk3MKkXuCRJkWkTnc1RmnOBSrm9Fqx8R7Ozuo7ko=; b=aj5BZAsHqUoyjyxn4Wh8W/sUBuXvGUgAs+dVBZY+2W4m85ivU2BqxKx4M+VhFUMj5K nysB+VMdCezYKfkg8b9rhyR4rIlWKLqFlIRWdxUqKh+TUZT9M72qBI5QMtHldZEaLazz ZLtBJ0Rzn6PrGEvWLSFbcGlkpCLbWbsYTKXVwsqv2Xufpt7/rHKJmap+Ulxi2zyHfUBl MBTkylkq+P2R2z0S/l6IhBvzz7NlObsObznBkQYQomkiPOT52nX82L/Fxb/vPWqpR6ZR s9gey2IrNcN2pljYQC8xPiUOn0tCDq1DUq3CDgNbBeTaav30MRr8efncrSk/n4+5qQ9M yZDw==
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; bh=9+Qrk3MKkXuCRJkWkTnc1RmnOBSrm9Fqx8R7Ozuo7ko=; b=APpD4WVuWEL2bZ6LNmexRoYb6L4Yle9IQcAUzxhpAwGVD1eatBcwUx68fvVtyhQweM nWatEFEUXxr65NjXCOX8fAeRd2eICxcTInezO7l4+EuZWagXimhJQDHY2AyElV/mnxxD 4/CM6KUZdLyudFJaYuiCr51kW4nkDESvFb5I3pFdWRBCuylH1LbmAO93JRpFHdmYIZFp esjXm9lAnz984rgvgATpsZTdAxMu3uiCUGyNzIpveUeTkmI9qWVov/sBlrTFVzKeSW8W /SFaVxHLI6KP0Z567+cy71/5W0acbq53+0CHb7NMXsEFes23cAXXkH9GFyB8O72zlIUr lJMQ==
X-Gm-Message-State: AD7BkJLpVV2kSW5vT4U1BOOIj8NyFDGA8GcOEzX1SlnI7mFmTvb7oAOrW+sp+wWlSMl5bj7sEwLGzevpdCNrFUk/
MIME-Version: 1.0
X-Received: by 10.50.59.242 with SMTP id c18mr32408074igr.4.1458144771004; Wed, 16 Mar 2016 09:12:51 -0700 (PDT)
Received: by 10.107.137.80 with HTTP; Wed, 16 Mar 2016 09:12:50 -0700 (PDT)
In-Reply-To: <CAAF6GDcAojmjOwuuwL-Vtk-U2VXa0JyXcqdZaDXrYmEuj=6eEA@mail.gmail.com>
References: <CAH9QtQGdZ9=XG-Qc5G6amM1pOnBse5jZndL0kExxArWXoQbhsQ@mail.gmail.com> <CAAF6GDegiWr3cWPpQAiVTZ5RhWFg24C-=SB=b=tKVTpaPn3V5g@mail.gmail.com> <CAH9QtQHvrz0guqGeMxD-C1ifCLOvOuADGdeqtCMHkEnRZ=y+hw@mail.gmail.com> <CAAF6GDc+Lnzpx38YT0gvgetb8E9yVsgMkLMh1SB7tu=fw_SK4A@mail.gmail.com> <CAH9QtQF02zwnB6dOGjFfWX2RLc4_RSODFpHaVLZkK_5KDf93sg@mail.gmail.com> <CAAF6GDd0h=1--pViASw3pT5nMAM4SRy2C2hzA6XF7Ba_g+oL4w@mail.gmail.com> <20160316081717.GA21439@LK-Perkele-V2.elisa-laajakaista.fi> <CAAF6GDcAojmjOwuuwL-Vtk-U2VXa0JyXcqdZaDXrYmEuj=6eEA@mail.gmail.com>
Date: Wed, 16 Mar 2016 09:12:50 -0700
Message-ID: <CAH9QtQHmoGTOcKK9yaiXY9Rtrt1k5Cc-iSX7E49L=G5A_krcNg@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
Content-Type: multipart/alternative; boundary=047d7bea423e1bccf1052e2cc9f4
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Tc_HxoG-Zlwdb_szUozAmD5GoiE>
Cc: "tls@ietf.org" <TLS@ietf.org>
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: Wed, 16 Mar 2016 16:12:53 -0000

On Wed, Mar 16, 2016 at 5:12 AM, Colm MacCárthaigh <colm@allcosts.net>;
wrote:

> On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara <ilariliusvaara@welho.com
> > wrote:
>
>> > Benefits Forward Secrecy and Idempotence:
>> >
>> > * Client and server should erase the existing ticket upon use.
>> >
>> > (a captured early data section is mooted for replay quite quickly in the
>> > default "good" case)
>>
>> The best that can be done w.r.t. "forward secrecy" is to erase the
>> decryption-capable key used for 0-RTT on both sides, and never sending
>> it on the wire, even encrypted.
>>
>
> That's why I favor resuming connections where they left off, and cranking
> a PRF to generate new keys; but it's not compatible with tickets at all -
> works only with some kind of session store.
>

We can emulate resumption where we left off with the new ticket extension,
as I try to do above in my "second attempt".  Clearly this requires very
careful implementation, or you would not have so easily broken my first
attempt on this thread.  This is why I think we should document it, and
encourage people to analyze its security properties very carefully.

If emulation of 0-RTT resumption from where we left off is found to be as
secure as 0-RTT resumption from a cache with all the prior connection
state, then I prefer the new ticket scheme because it also supports the
riskier stateless forms of 0-RTT, which can improve speed, resumption
success rates, and lower costs (QUIC does all three).

I would love to see careful cryptanalysis of what we feel is the simplest
secure 0-RTT mode we can offer with TLS 1.3 as it is today.

One thing that helps me with analysis that I do not think is clear from the
spec: the client MUST save the entire session state to do PSK resumption,
other than:

- the previous session secrets which should be erased and replaced with the
resumption master secret
- the TLS sequence numbers since the keys changed.

Is this accurate?  I think it is important for security analysis.

Bill