Re: [TLS] 0-RTT and Anti-Replay

Nico Williams <nico@cryptonector.com> Mon, 23 March 2015 17:16 UTC

Return-Path: <nico@cryptonector.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 64F431ACE59 for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 10:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.366
X-Spam-Level:
X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 ATzjpGuWTZGz for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 10:16:35 -0700 (PDT)
Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A76721ACE58 for <tls@ietf.org>; Mon, 23 Mar 2015 10:16:35 -0700 (PDT)
Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 867CF2005E61E; Mon, 23 Mar 2015 10:16:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=VZ4VYGHzqSuGabHBSjMJRKCGgQk=; b=mCej2MzF5wX yLss0iJ/Q/8aQQhJL24StOqYR0LLNvAGsGOaRvkvb+yePCsUb9mvRSVFuypLo8eI 0hNy5F8IKg5DU6u7jCHB3E2wL56B5hE35lihfafDSQDOgsat9kXLHCtQ8LMF7keU NxU+oQFPMsybM3Tnz5TMCXPPGZw/3f6w=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id A03152005E61C; Mon, 23 Mar 2015 10:16:34 -0700 (PDT)
Date: Mon, 23 Mar 2015 12:15:32 -0500
From: Nico Williams <nico@cryptonector.com>
To: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= <colm@allcosts.net>
Message-ID: <20150323171532.GO21267@localhost>
References: <550F6582.9040602@brainhub.org> <CABcZeBNn92Zu7Hfu5z8qD=AZDn=jUkZ3phk18G7S1z7XJNQ9sQ@mail.gmail.com> <CABkgnnWXtpuSKH-eEou9O7qncUSeuiv=4kw_GE6Um8VW3dcohQ@mail.gmail.com> <20150323083308.GL21267@localhost> <20150323144052.GF9387@mournblade.imrryr.org> <55102E3A.70300@zinks.de> <20150323152831.GG9387@mournblade.imrryr.org> <55103A6E.4060409@zinks.de> <20150323162200.GI9387@mournblade.imrryr.org> <CAAF6GDdg7mBJuH9D0vDHE9G5dsQUd_iTGadeDjtYsT5ecZYkzw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <CAAF6GDdg7mBJuH9D0vDHE9G5dsQUd_iTGadeDjtYsT5ecZYkzw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/3m8F2ynd_XjoehQXclBpLzos38k>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 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: Mon, 23 Mar 2015 17:16:36 -0000

On Mon, Mar 23, 2015 at 09:44:16AM -0700, Colm MacCárthaigh wrote:
> On Mon, Mar 23, 2015 at 9:22 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>; wrote:
> > Deliberately so, for people who know what they are doing, to support
> > latency sensitive idempotent requests that don't need request replay
> > protection.
> 
> Should using TLS securely rely on that level of expertise? it is also
> an incredible temptation to have the possibility of optimistic
> execution, and just not pay any attention to the idempotent (or
> reliability) issues.

In some sense this is unavoidable.

Consider channel binding.

In the SASL/GS2 framework we use the GSS channel binding data input to
deliver data beyond just proper channel binding data, but the data so
delivered is negotiation data.  (Integrity protection of that data is
delivered eventually.)

Now, TLS may not have a proper channel binding data _input_, but
developers, I'm sure, could marshall something.

Imagine a StartTLS protocol where the client sends a request (launch
missiles) and a request/offer to upgrade to TLS, with subsequent
integrity protection of the "0-RTT" data from the first request: if the
server has acted on the 0-RTT data by then, it's too late.

Therefore it seems that the issue is somewhat unavoidable even if we
exclude a 0-RTT mode in TLS, and so we should describe the associated
security considerations.

Nico
--