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

Nico Williams <nico@cryptonector.com> Mon, 23 March 2015 08:34 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 0AAC81A00BF for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 01:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 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, 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 Vk_rz3IPYx4P for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 01:34:41 -0700 (PDT)
Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 65C9B1A0084 for <tls@ietf.org>; Mon, 23 Mar 2015 01:34:41 -0700 (PDT)
Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 2C3D42005D005; Mon, 23 Mar 2015 01:34:41 -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; s=cryptonector.com; bh=ADMiEs0JwCSni9 0bngz+fEt8Vuk=; b=Oy0nbUM4fxWQNmy6n8dqFocQUl0qnEte58+gMA9Yws7+8H 945xieiKnnCADOvRJaf2DV5rNGQajPpGvENfnZcJLFwapyWUFPEwbr2/3aPA85D7 aep/DfW4NMFzwYmWSInLpgwIbOFe/xZRZ30iDgbi92M6BY1idOpudsbw95ad4=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id D09AB2005D004; Mon, 23 Mar 2015 01:34:40 -0700 (PDT)
Date: Mon, 23 Mar 2015 03:33:09 -0500
From: Nico Williams <nico@cryptonector.com>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20150323083308.GL21267@localhost>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com> <550F6582.9040602@brainhub.org> <CABcZeBNn92Zu7Hfu5z8qD=AZDn=jUkZ3phk18G7S1z7XJNQ9sQ@mail.gmail.com> <CABkgnnWXtpuSKH-eEou9O7qncUSeuiv=4kw_GE6Um8VW3dcohQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABkgnnWXtpuSKH-eEou9O7qncUSeuiv=4kw_GE6Um8VW3dcohQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/WjzIMpakj-GE0Oj_RLPIDCXaRx8>
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 08:34:42 -0000

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.

Nico
--