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

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Wed, 13 May 2015 20:58 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 8244D1A8F39 for <tls@ietfa.amsl.com>; Wed, 13 May 2015 13:58:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.399
X-Spam-Level: *
X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 eZTQcUjJNvWY for <tls@ietfa.amsl.com>; Wed, 13 May 2015 13:58:21 -0700 (PDT)
Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0561A8AC4 for <tls@ietf.org>; Wed, 13 May 2015 13:58:21 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id C3476188780; Wed, 13 May 2015 23:58:18 +0300 (EEST)
Date: Wed, 13 May 2015 23:58:17 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20150513205817.GA24851@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> <20150414054606.GA7053@LK-Perkele-VII>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20150414054606.GA7053@LK-Perkele-VII>
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/HqTNTpmMz7evxsqKBg03M-gpU40>
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: Wed, 13 May 2015 20:58:23 -0000

On Tue, Apr 14, 2015 at 08:46:06AM +0300, Ilari Liusvaara wrote:
> 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).

Well, the question is really where the keying material for encrypting/
decrypting 0-RTT is obtained. There are three obvious candidates:

1) (x*S_old = s_old*X, ClientRandom)
2) (rPMS, ClientRandom)
3) (PSK, ClientRandom)


[(x*S=s*X, ClientRandom) and (x*S_new=s_new*X, ClientRandom) do not
work, the first is mathematically ill-defined, and the second
is uncomputable for client]

Each is obvious candidate to one server key exchange type:
1) for full DHE handshake.
2) for abbrevated handshake.
3) for full pure-PSK handshake.

However, no other combination works well, either because it makes
the server sad, or the server doesn't have the needed keys. Unifying
abbrevated and pure-PSK handshakes doesn't help much here (since
keys presumably won't match).


Now, the real issue:
Suppose that client is willing to accept multiple of the three key
exchange types (full-DHE, abbrevated and pure-PSK) at once. Now,
all three are expected to use different keys. Under what keys does
client encipher the 0RTT data?

Indirect keying (key wrapping) leads to "interesting" security
analysis, as inner encryption effectively becomes unauthenticated.


(Also, the used 0-RTT key, if any has to be mixed in with appMS
to prevent an attack).


-Ilari