[TLS] 0RTT?

Watson Ladd <watsonbladd@gmail.com> Sun, 03 August 2014 17:09 UTC

Return-Path: <watsonbladd@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 0CD481A0AED for <tls@ietfa.amsl.com>; Sun, 3 Aug 2014 10:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.499
X-Spam-Level:
X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_46=0.6, 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 TJe9rX7N7j6l for <tls@ietfa.amsl.com>; Sun, 3 Aug 2014 10:09:02 -0700 (PDT)
Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1DF1A0AEA for <tls@ietf.org>; Sun, 3 Aug 2014 10:09:02 -0700 (PDT)
Received: by mail-yh0-f42.google.com with SMTP id a41so3717289yho.15 for <tls@ietf.org>; Sun, 03 Aug 2014 10:09:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Z/SOquxGxMsh70BmOlKj28kfvNa1f3Yiqvbl1WFvml0=; b=m4X8g08nn46eqMPmzAeq9SJJVGeoQ4x60bRuxE+OtbNKTXkk+psw+chfnFdx2+/CDU SlbbLRmcQJOA6+kpANH9Sr8WPp/AMsK633ITQ8D4BxsJ7lUQnF72AwIx0X9K2r/BiaOb gGXSxOnuJVxVR9rVHQl5IDVPsMy376DedxEVpCwM+FIay2KuarY/X/5XrV5R96QDWu4l fRWpCjWvr1seE84TneVPR8cVnU+abNSOzxjs0dH8RkmG0TGC9jGZS0XFgm0u6Vb4jv0X JPsvUX+VXlj907Mn783/LrlfWD0/VzUJ0ffpb16AFnkmDYY/TRmjy9nzHkzsRyPnMpDM AbKQ==
MIME-Version: 1.0
X-Received: by 10.236.172.161 with SMTP id t21mr30533364yhl.65.1407085741551; Sun, 03 Aug 2014 10:09:01 -0700 (PDT)
Received: by 10.170.202.8 with HTTP; Sun, 3 Aug 2014 10:09:01 -0700 (PDT)
Date: Sun, 03 Aug 2014 10:09:01 -0700
Message-ID: <CACsn0c=wUvV1M0kZ2y6OcC_UPoRtBRz1Nh_zb_sLYamozoPrpw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yTiex20P2nVc-hsz7DG_AhijE0s
Subject: [TLS] 0RTT?
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, 03 Aug 2014 17:09:05 -0000

Dear all,

I think I came up with a decent idea for handling 0RTT handshakes,
namely making resumption 0RTT, and doing a side rekeying.

To see this work we assume that the usual resumption ticket gets set
in the handshake, and determines the PMS. A resumption looks as
follows:

-The ticket
-An anti-replay nonce: BLAH bytes
-A refresh key: since we know what the server wants, we can provide a
group it supports

The PMS that gets used is PMS_interim= HMAC(old_PMS, nonce || refresh
key): data encrypted as usual under the old ciphersuite follows. (Note
that we may have to include the entire Client Hello hashed: this is
probably easier, except that the data goes in the Client Hello when
using the current inclusion mechanism)

On receiving this a server looks up the anti-replay nonce and checks
it is fresh. To make this easier we include UTC time since the epoch (
midnight of 1 January 1970) and mandate some degree of synchronization
and a window. To avoid tagging with clock drift we truncate some low
order bits after adding a random small offset.

If the nonce is not previously seem the server can send Application
Data as normal.

We now introduce a new handshake type: Rekey Finish, containing a new
ticket and server key. CCS follows afterwards. These are sent
encrypted.

The new PMS will be HMAC(PMS_interim, ECDH(server, client keys)).

The big limitation is ticket keys are going to need rotation. This
also doesn't address the desire to put extra data in DNS to give some
degree of forward secrecy, but I don't think you can change DNS that
quickly without some problems.

Furthermore, if we want rekeys without renegotiation, we can reuse
Rekey Finish and add a Rekey Initiate handshake type that will send
the client key.

Open questions: how secure is this? We certainly need to hash the
anti-replay nonce into the keys: is that all we need? (Not if we want
to avoid attackers manipulating which method we use) Does noisy
truncation work to prevent fingerprinting while reducing storage
requirements?

Sincerely,
Watson Ladd