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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 23 March 2015 16:22 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 D4C621AC418 for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 09:22:03 -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 Y0hrjE5yjwU8 for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 09:22:02 -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 6579D1A92B6 for <tls@ietf.org>; Mon, 23 Mar 2015 09:22:02 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DD049283011; Mon, 23 Mar 2015 16:22:00 +0000 (UTC)
Date: Mon, 23 Mar 2015 16:22:00 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150323162200.GI9387@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> <20150323144052.GF9387@mournblade.imrryr.org> <55102E3A.70300@zinks.de> <20150323152831.GG9387@mournblade.imrryr.org> <55103A6E.4060409@zinks.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55103A6E.4060409@zinks.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/qJCh-GVLPReTHNxQCekbY5JpwU0>
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 16:22:04 -0000

On Mon, Mar 23, 2015 at 05:08:14PM +0100, Roland Zink wrote:

> > >Often there is a whole software stack on top of TLS. You probably can't
> > >forward the requirements through the complete software stack.
> >
> >That's good.  Such software stacks will not be 0-RTT aware, and
> >must not see 0-RTT data.  Only stacks explicitly designed for 0-RTT
> >will get to play.
>
> Seems like very limited use,

Deliberately so, for people who know what they are doing, to support
latency sensitive idempotent requests that don't need request replay
protection.

> but still when somebody builds something on top of such a stack not knowing
> that something special needs to be done.

They lose.

    * If clients make 0-RTT requests to a stack that does not
    support these, all connection abort when the stack requests
    non-expedited data, while expedited data is pending.

    * If the stack requests expedited data without an explicit
    request from the server application to do that, it is broken.
    Vulnerability reports will be filed, everyone will run around
    patching, ...

> Simplest may be a HTTP library thinking GET requests are idempotent, which
> they should, and is doing 0-RTT and the server does something on the GET
> request like fire some missiles.

HTTP libraries have no business doing that (bring on the sky is
falling vulnerability reports, emergency patch cycles, ...).  The
application would have to explicitly signal support for such
requests, and when they arrive they'd have to be clearly tagged as
such consistent with the API that enabled their delivery.

-- 
	Viktor.