Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay)

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Thu, 14 May 2015 05:59 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 819CF1B33B7 for <tls@ietfa.amsl.com>; Wed, 13 May 2015 22:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ygO-SeM4ZftS for <tls@ietfa.amsl.com>; Wed, 13 May 2015 22:59:33 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957E31B33B0 for <tls@ietf.org>; Wed, 13 May 2015 22:59:32 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id DB5CD818AA; Thu, 14 May 2015 08:59:29 +0300 (EEST)
Date: Thu, 14 May 2015 08:59:29 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Nico Williams <nico@cryptonector.com>
Message-ID: <20150514055929.GA27098@LK-Perkele-VII>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com> <20150412165542.GA19481@LK-Perkele-VII> <20150513222927.GZ7287@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20150513222927.GZ7287@localhost>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/2Q9yRq2vtz5w1dQXDFVydfhGfqI>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay)
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: Thu, 14 May 2015 05:59:42 -0000

On Wed, May 13, 2015 at 05:29:29PM -0500, Nico Williams wrote:
> On Sun, Apr 12, 2015 at 07:55:42PM +0300, Ilari Liusvaara wrote:
> 
> > 2) What are the semantics of successfully received 0-RTT transfer
> >    (especially considering the client-side autoretransmit on
> >    failure)?
> 
> Leave it to the app.  A replay cache option would be nice, but the app
> probably needs to provide this itself (since, after all, it's not just a
> question of "have we seen this before", but also, "have we processed
> this before").

If 0-RTT fails, client's first reaction is probably to replay the failed
0-RTT data, or something equivalent to it...

> > 3) How does 0-RTT interact with ALPN (especially considering
> >    potential for multiple protocol candidates)?
> 
> The client has committed to an application protocol.
> 
> Although that's not necessarily quite so true: elsewhere we're talking
> about an RFC2712 (Kerberos in TLS) replacement where ideally we could
> start sending GSS-API context tokens as early as possible (when the
> client doesn't want confidentiality protection for its name).  Such a
> protocol could still negotiate from N>1 application protocols.
> 
> (GSS-in-TLS as an application protocol using 0-RTT data is a perfect
> example of a *safe* use of 0-RTT data, provided that the intention is to
> also do channel binding.  Don't think about GSS too hard here.  Just
> think about the point that some 0-RTT uses will be quite safe.)

So consideration that only put compatible ALPN IDs (that could lead
to connection failures, due to incomplete set)?
 
> > 4) Can handshake with attempted 0-RTT be securely downgraded to
> >    v1.2 (obviously causes the 0-RTT to fail)?
> 
> Sure, but the 0-RTT data must get dropped.

Actually, thinking about it, ability to tolerate downgrade (losing
0-RTT) isn't that important if one has already to restrict ALPN.

> > 8) If resumption attempt has 0-RTT data, what keying material is
> >    used for the 0-RTT?
> 
> In principle, none.  However, a key derived from the resumption ticket's
> session key would be nice.  See below.
> 
> The PSK case could be similar as well.

Well, None means unencrypted? :-)

And yes, resumption ticket / PSK key would be nice, saves server
quite expensive asymmetric-key operation.

> > 9) Can server roll over its 0-RTT keys without waiting for the
> >    previous ones to expire?
> 
> In relation to (8)?  No.  But we could do something where we use
> timestamps, a la Kerberos, to greatly reduce the time window that any
> replay caches have to protect, at least for session resumption 0-RTT
> data!

I mean server doing full (DH) handshake, accepting 0-RTT and signaling
new 0-RTT keys for future connections in the same connection.

(Obviously if session keys are used, the 0-RTT keys expire with the
session context).

I.e.

C->S: [full DH, 0-RTT data: encrypted using x*S_0, (kid k_0)]
S->C: [0-RTT accepted]
S->C: [new 0-RTT key S_1 (kid k_1), expected valid until T_1]
S->C: [Handshake complete]

(In "DH-based" key exchange, it is undefined behaviour for server
to attempt that, since it makes no distinction between old and new
key).

> > 10) How is attacker establishing a session (or at least decoding
> >     server's first application flight) replaying captured
> >     0-RTT data prevented (since that could leak quite a bit of
> >     info about what's in 0-RTT blob)? Or not?
> 
> IIUC, it isn't.

AFAIK, if 0-RTT is accepted, hashing in 0-RTT keys (or closely
related values) should take care of that.


-Ilari