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, 4 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.