Re: [TLS] 0RTT?
Martin Thomson <martin.thomson@gmail.com> Mon, 04 August 2014 17:54 UTC
Return-Path: <martin.thomson@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 44AAA1A00AB for <tls@ietfa.amsl.com>; Mon, 4 Aug 2014 10:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 6s3yUEOnDwtp for <tls@ietfa.amsl.com>; Mon, 4 Aug 2014 10:54:19 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EEA41A00A8 for <tls@ietf.org>; Mon, 4 Aug 2014 10:54:19 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id d1so5531911wiv.13 for <tls@ietf.org>; Mon, 04 Aug 2014 10:54:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WiUTwjMnUCfKA3s+rvxRvpAYMP73VMAH+8yzKuynInQ=; b=CtlH7GNXnOLI3UoTM0zbsYKv4T5v6SdqGpHC1yrmTDOEXe/kVqhJ7Lqb7rn2l4UGfz r9/7OMWKOV3cS1/oumfBt0OgLmc9DBjIZFiQBqPpRy04cfaAsjtpyKrJE0hHJd37vHJr ZUTazbLjvx0p6/h3Cvk5ANWpJc6ruhDqCnP0K02hxG5kWwRiPD2qF9Ii8GkdepicMl7j /dVgX9325EmAwUW/EvtYkxWdLRV6wFJt1dLIKRx5KNr3Ma5xkImELoeJN5ysHxHxOKTO bxW2f7IAoMwswkcSq84KTi/rhn0lYl9KI07cEZE9An4lwhk5lOdQGWZoPt0rrv25aohz veEw==
MIME-Version: 1.0
X-Received: by 10.194.185.238 with SMTP id ff14mr34275634wjc.9.1407174857919; Mon, 04 Aug 2014 10:54:17 -0700 (PDT)
Received: by 10.194.6.229 with HTTP; Mon, 4 Aug 2014 10:54:17 -0700 (PDT)
In-Reply-To: <CACsn0c=a5MXuBe1Fgkyytnwnq=mO7NmWgJ=9Kq16fiEBh-DCEw@mail.gmail.com>
References: <CACsn0c=wUvV1M0kZ2y6OcC_UPoRtBRz1Nh_zb_sLYamozoPrpw@mail.gmail.com> <CABkgnnWQn1D306KSJ70Qqe1=PJJ=wH=sy830=2kbzo0eLjjiSg@mail.gmail.com> <CACsn0c=a5MXuBe1Fgkyytnwnq=mO7NmWgJ=9Kq16fiEBh-DCEw@mail.gmail.com>
Date: Mon, 04 Aug 2014 10:54:17 -0700
Message-ID: <CABkgnnV6p=kDGWvqm7xMmexUxDE2_032ZYU73sGzvvAmrrnTPA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/r2ehA6JyJy6e4jbHJwDQRI9-mCk
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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: Mon, 04 Aug 2014 17:54:21 -0000
On 3 August 2014 19:43, Watson Ladd <watsonbladd@gmail.com> wrote: > That has costs with key rotation and administrative version. Maybe > those aren't so bad. But I would like to see resumption be 0RTT also: > right now it is 2RTT in TLS 1.2. One thing I like with your proposal is that it looks a lot like the 0RTT proposal, but with a different key derivation path that avoids the "expensive" operation. If the rekeying is optional it diverges some, but no so badly. I see the following choices for a server that receives a handshake in this form: a. Regarding the data, the server can accept the data or not b. Regarding the keying material, the server can continue to use the indicated "master secret", or it can request that a new DH exchange be completed ** Here we could also enable other options, like having the server offer a backwards reference for authentication, or maybe you can renegotiated ciphersuite... I think that would be unnecessary complexity; if you continue based on the previous session, then I'd prefer not allowing anything to change about the session; if you want to change anything, the server can re-run a full handshake. I think that the choice regarding the data is largely orthogonal to the choice regarding the keying material. These seem to be the most relevant choices: 1. accept the data and keys, continue with the provided keys 2. reject the data, but continue with the provided keys 3. accept the data, but re-run the handshake 4. reject the data and re-run the handshake The two options being what is new here. The proposed 0RTT mode allows the latter options only. The case where the server rejects the data is a little odd, but it might be that the server doesn't want to do nonce-checking; and it is closest to the 1.2 resumption handshake.
- [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