Re: [TLS] TLSv1.3 Cookies

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 13 September 2017 16:08 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7414E133064 for <tls@ietfa.amsl.com>; Wed, 13 Sep 2017 09:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 OzeuB1t4FoYW for <tls@ietfa.amsl.com>; Wed, 13 Sep 2017 09:08:51 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293CC132C32 for <tls@ietf.org>; Wed, 13 Sep 2017 09:08:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 7BE60B5261; Wed, 13 Sep 2017 19:08:48 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id cZo21ThUlxbD; Wed, 13 Sep 2017 19:08:48 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id E50FC2313; Wed, 13 Sep 2017 19:08:45 +0300 (EEST)
Date: Wed, 13 Sep 2017 19:08:45 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Matt Caswell <frodo@baggins.org>
Cc: "tls@ietf.org" <tls@ietf.org>
Message-ID: <20170913160845.khjf5odas3ns5u5z@LK-Perkele-VII>
References: <CAMoSCWYXWJMkFAdrcy033_bjMZjRUiU-V5f8MkoTXyvDfw+z6A@mail.gmail.com> <20170913150929.nupe6fq5rqtroflp@LK-Perkele-VII> <CAMoSCWapcL_xPLvkm6ey+Go1U+4Z_y2bZbKqCRPSHntFj3G41w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAMoSCWapcL_xPLvkm6ey+Go1U+4Z_y2bZbKqCRPSHntFj3G41w@mail.gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yWHzf32BigS8KqLTP2dCk4-uo6s>
Subject: Re: [TLS] TLSv1.3 Cookies
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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 Sep 2017 16:08:53 -0000

On Wed, Sep 13, 2017 at 04:24:37PM +0100, Matt Caswell wrote:
> On 13 September 2017 at 16:09, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> > On Wed, Sep 13, 2017 at 03:53:46PM +0100, Matt Caswell wrote:
> >> I am looking at trying to implement the TLSv1.3 stateless cookie
> >> mechanism (in order to be able to support QUIC stateless retries).
> >>
> >> I am not clear how cookies are supposed to interact with early_data.
> >> Consider the scenario where a server is operating statelessly. Because
> >> there is no state each ClientHello looks like the first one it ever
> >> saw. The server only knows that a particular ClientHello is actually a
> >> ClientHello2 following an HRR because of the state held in the cookie.
> >
> > Looking at the definitions of Cookie and EarlyData extensions, those
> > two are mutually exclusive. That is, there can be three kinds of
> > ClientHello messages:
> >
> > 1) Contains neither Cookie nor EarlyData.
> > 2) Contains an EarlyData, but not Cookie.
> > 3) Contains a Cookie, but not EarlyData.
> >
> > (This exclusivity arises because Cookie can only be present in a retry,
> > but EarlyData is stripped out for retry).
> >
> >> What happens when a client attempts to send early data to such a
> >> server? The server will process the ClientHello and determine that
> >> there is no cookie, sends back an HRR and then forgets all of its
> >> state and waits for the next ClientHello. However what it actually
> >> gets next is early_data. It does not know that that early data
> >> followed an earlier ClientHello (because it is stateless) so it does
> >> not know to skip the records. It just looks like illegal records so,
> >> presumably, it will respond with an alert.
> >
> > Yes, if one receives a ClientHello with both Cookie and EarlyData, one
> > can reply with a fatal alert, because that is not supposed to happen.
> 
> That isn't quite the scenario I was talking about. Rather your case
> (2) above in a server which is operating statelessly, i.e. the client
> has attempted to send early_data but has not provided a valid cookie
> yet. The early_data when it arrives will look like bad packets, even
> though (from the client perspective) it was valid to send them.

If you really got some transport that uses TLS on something where
stateless operation makes sense (so not TCP) that transports the 0-RTT
TLS data in-band (so not QUIC), just throw any initial records starting
with 0x17 into trash.

AFAIK, QUIC does not use TLS 0-RTT data, it uses 0-RTT exporters to
derive encryption keys for data, that is sent outside TLS. So in
that case, TLS would see two consequtive ClientHello messages if the
first gets rejected.


-Ilari