Re: [TLS] 0RTT?

Eric Rescorla <ekr@rtfm.com> Mon, 04 August 2014 03:11 UTC

Return-Path: <ekr@rtfm.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 021C81A00C2 for <tls@ietfa.amsl.com>; Sun, 3 Aug 2014 20:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 E7gGuvBwp4hV for <tls@ietfa.amsl.com>; Sun, 3 Aug 2014 20:11:28 -0700 (PDT)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909801A00BE for <tls@ietf.org>; Sun, 3 Aug 2014 20:11:27 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id a1so6985913wgh.35 for <tls@ietf.org>; Sun, 03 Aug 2014 20:11:26 -0700 (PDT)
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:from:date :message-id:subject:to:cc:content-type; bh=a+DeVbyDvq7DF89ATpUUVrqL+RGlqOJWuCWMxrhK3Rw=; b=AjOJb26ejsJHfMMh0/NCPncAJ3HyIRj8YYPUmAqfGlmt4oXiUV5d8PasedocXmyN5Y u52z6YUb3N99y3h3QWA5nVxdUM76cqNTdc8hpvSKCSXIqilmn2iQ++YCxQJyp+C2gzif 9QX3oodB+CErtfmPbHMWKlkhSJMc0PSJJFRMo4L8QMyIZaVsbzTuQyU0+WgHBEtWLmN3 kOBq/6NkCJhfuiFODsUS7S3i0FN1xA2X8avDyAyRGfqNuz6Kl85s1zAy16UqJOJ4S4mC l8Q6qa0h08iTJgr809YK/3Fy7PJIN5b1NioQ/geZ45Pm0SnKumnVXi5zXt7Lcghxp/vu 7/vQ==
X-Gm-Message-State: ALoCoQkRxTDdrpHzRoorDuIpWw5TE5a/G1jj/0ZpwdA1pZ8AChyYC2kojXgQWHArWaOajDycTtwI
X-Received: by 10.180.98.163 with SMTP id ej3mr25143927wib.36.1407121886157; Sun, 03 Aug 2014 20:11:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.128.12 with HTTP; Sun, 3 Aug 2014 20:10:46 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <CACsn0c=wUvV1M0kZ2y6OcC_UPoRtBRz1Nh_zb_sLYamozoPrpw@mail.gmail.com>
References: <CACsn0c=wUvV1M0kZ2y6OcC_UPoRtBRz1Nh_zb_sLYamozoPrpw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 03 Aug 2014 20:10:46 -0700
Message-ID: <CABcZeBMqrNPh7Qt0hqxyf=b1+=dR+E-GRrTZBmkce25m+9jo2g@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="f46d0442877a2e39cb04ffc51836"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eC0bNfVyKz-CX_VstG1420xxA8M
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 03:11:33 -0000

Watson,

Interesting suggestion.

It does seem like a good idea to allow 0-RTT with resumption, assuming
we retain resumption but I'm not sure we really want to couple resumption
and 0-RTT, since that would mean that there's no way to get 0-RTT first
handshakes even when the server has some out-of-band way of publishing
his key, such as in DNS or WebRTC SDP (this is a real issue for WebRTC,
where we *do* have an out-of-band channel for signaling.)

The basic property of 0-RTT is that the client can share
a key with the server on the first message and that's compatible
with both session resumption and a semi-static server DH key
(See, for instance:
http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-6.3,
figure 5). It should be possible to design a 0-RTT mechanism that
works for both.


Also, I would also suggest that we separate out the exact design of the
anti-replay mechanism from the question of whether 0-RTT and resumption
go together. Generally, these mechanisms have some kind of scoping
mechanism (e.g., a server-provided context string and a timestamp,
as in Snap Start) and then a client-provided nonce. The details seem
like something we can tune separately. It's also worth observing that
if you encrypt the scoping values you can significantly reduce their
privacy exposure, since only the target server gets them.

Best,
-Ekr




On Sun, Aug 3, 2014 at 10:09 AM, Watson Ladd <watsonbladd@gmail.com> wrote:

> 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 mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>