[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
- [TLS] 0RTT? Watson Ladd
- Re: [TLS] 0RTT? Karthikeyan Bhargavan
- Re: [TLS] 0RTT? Watson Ladd
- Re: [TLS] 0RTT? Martin Thomson
- Re: [TLS] 0RTT? Watson Ladd
- Re: [TLS] 0RTT? Eric Rescorla
- Re: [TLS] 0RTT? Eric Rescorla
- Re: [TLS] 0RTT? Martin Thomson
- Re: [TLS] 0RTT? Martin Rex
- Re: [TLS] 0RTT? Watson Ladd
- Re: [TLS] 0RTT? Martin Rex