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

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Tue, 14 April 2015 05:46 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 401D11B33D3 for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 22:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 rtWaUHf3ED_L for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 22:46:11 -0700 (PDT)
Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4B01B33D2 for <tls@ietf.org>; Mon, 13 Apr 2015 22:46:09 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 0E9B4402B; Tue, 14 Apr 2015 08:46:06 +0300 (EEST)
Date: Tue, 14 Apr 2015 08:46:06 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20150414054606.GA7053@LK-Perkele-VII>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com> <20150412165542.GA19481@LK-Perkele-VII> <CABkgnnUr4wYkVwBGvH0MSmBnzNBd+T1s4aZJ5OvT_Gw3UyMSjQ@mail.gmail.com> <20150413181144.GA720@LK-Perkele-VII> <CABkgnnX6TqtUAV7zK8Cp6z25fJotiC22AXdkkXUhK6nnso9mBg@mail.gmail.com> <20150413191733.GB1016@LK-Perkele-VII> <CABkgnnVNFtri6sGMntEg7uNUMVsxbqReQ5-L5cTg=43FsOMr4A@mail.gmail.com> <20150413194605.GA1377@LK-Perkele-VII> <CABkgnnUiUXHxrUE+Hxi7Nzjpg0xUs6c3A7+WBnWJkvtU+W0BNg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABkgnnUiUXHxrUE+Hxi7Nzjpg0xUs6c3A7+WBnWJkvtU+W0BNg@mail.gmail.com>
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/Xt3kdMITaA5JEih8N4e0eLXVyxU>
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: Tue, 14 Apr 2015 05:46:14 -0000

On Mon, Apr 13, 2015 at 12:57:51PM -0700, Martin Thomson wrote:
> On 13 April 2015 at 12:46, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>; wrote:
> > On Mon, Apr 13, 2015 at 12:30:04PM -0700, Martin Thomson wrote:
> >>
> >> You assume that 0-RTT doesn't fall into that third category.  I hadn't.
> >
> > Well, the only examples of 3) I can come up with would be
> > - Resumption-only (fail enteriely if not resumable)
> > - Something possibly triggering some new type (neither 1RTT, 2RTT
> >   nor abbrevated) of handshake.
> >
> > Of course, I then have trouble even thinking what such new type
> > of handshake could be.
> 
> Well, 0-RTT could be a third category.  As Hugo originally proposed
> it, this would have the authentication of the connection be based on
> successfully proving the ability to generate g^xy.  That's stronger
> than resumption, but relies on the authentication of a previous
> session in the same way that resumption does.  You might consider that
> to be resumption, or not.

I don't consider that to be resumption, since asymmetric crypto is
involved (the whole point of resumption is to avoid asymmetric
crypto).

And furthermore, I don't think it is worth the trouble to introduce
a different kind of handshake for 0RTT case.


I think the idea was (for non-resumption) to derive the 0RTT key from
DH result of client exchange key[1] (possibly with PSK) and cached medium-
term server key.

For resumption, one could derive the 0RTT key from resumption PMS.

The trouble with actual session resumption attempts comes from the fact
that these derive different keys (and at least in threat models I use,
one can't assume key wrapping works).


[1] To prevent that "replay and connect" attack mentioned previously,
either this has to be the actual client exchange key (there can be only
one), key exchange gets complicated since there is now a conditional
input or server can't roll its keys properly.



-Ilari