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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 23 March 2015 14:40 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 CFC561A8AFA for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 07:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 63NYu-Djej5z for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 07:40:54 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1891A8AF8 for <tls@ietf.org>; Mon, 23 Mar 2015 07:40:54 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 95324283011; Mon, 23 Mar 2015 14:40:52 +0000 (UTC)
Date: Mon, 23 Mar 2015 14:40:52 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150323144052.GF9387@mournblade.imrryr.org>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com> <550F6582.9040602@brainhub.org> <CABcZeBNn92Zu7Hfu5z8qD=AZDn=jUkZ3phk18G7S1z7XJNQ9sQ@mail.gmail.com> <CABkgnnWXtpuSKH-eEou9O7qncUSeuiv=4kw_GE6Um8VW3dcohQ@mail.gmail.com> <20150323083308.GL21267@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150323083308.GL21267@localhost>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/hFSHPDYtSIKFjdh0tUI86rizPpg>
Subject: Re: [TLS] 0-RTT and Anti-Replay
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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 14:40:57 -0000

On Mon, Mar 23, 2015 at 03:33:09AM -0500, Nico Williams wrote:

> On Sun, Mar 22, 2015 at 08:35:34PM -0700, Martin Thomson wrote:
> > For HTTP, I think we can use that first flight for idempotent queries
> > quite easily and (at worst) the HTTP/2 connection preface.
> 
> But TLS can't know what's happening at the application layer, so it had
> better be the case that the 0-RTT data is clearly denoted to the app as
> "had better be idempotent".  I.e., this becomes an API issue.  The name
> of the method would have to be indicative of danger.
>
> 0-RTT data is acted on at great risk.  It's OK to use it for negotiation
> purposes where the integrity of the negotiation will eventually be
> confirmed (else the connection fails).  For things like "launch
> missiles" it is a very bad idea to act on the command before
> authenticating it and determining that it's not a replay.  When we don't
> know the nature of the data, we must assume it can't be sent without
> authentication and replay protection.

Therefore, 0-RTT data must:

    * Require a non-default code path to send, (explicit request
    by the client to send a 0-RTT message).

    * Require a non-default code path to *receive*.  That is,
      the server must be configured to allow receipt of such data,
      and must explicitly request to read it.  If the server issues
      a read for protected data, while expedited 0-RTT data is
      pending, the connection should be aborted by the server's
      TLS stack.  Once the server exhausts all the expedited
      data, it can switch to reading protected data.

    * The server's TLS stack must not coallesce 0-RTT expedited
      (idempotent) data with subsequent protected data.

This allows servers that receive idempotent queries to avoid the
1-RTT latency.  Something akin to DNS lookups over TLS, (I am not
specifically advocating TLS as a transport for DNS in this message).

Servers reading expedited 0-RTT data will be aware that they are
doing that, and can/should reject operations that are unsafe in
that context.

This avoids all futile attempts to add stateful replay protection
to a stateless phase protocol.  I expect such attempts are doomed
to failure.

-- 
	Viktor.