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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 23 March 2015 15:28 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 572FC1A907E for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 08:28:38 -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 EdJDdNynAGKr for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 08:28:37 -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 E7C261A8FD6 for <tls@ietf.org>; Mon, 23 Mar 2015 08:28:32 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D1214283011; Mon, 23 Mar 2015 15:28:31 +0000 (UTC)
Date: Mon, 23 Mar 2015 15:28:31 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150323152831.GG9387@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55102E3A.70300@zinks.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/XFSYOshv1Jt-sbvDOXxtQeC81Ac>
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 15:28:38 -0000

On Mon, Mar 23, 2015 at 04:16:10PM +0100, Roland Zink wrote:

> >>     * The server's TLS stack must not coalesce 0-RTT expedited
> >>       (idempotent) data with subsequent protected data.
>
> 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.

> >>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).
>
> Even DNS queries may have side effects, for example when it is used to do
> load balancing.

DNS "load-balancers" are really latency optimizers, they don't
actually know how much load they are directing at servers because
there is a not a 1-to-1 mapping between DNS requests and service
requests.  There should be no state changes based on the observed
DNS queries, and if even there are, nothing tragic happens.  The
intended application here would be confidentiality only.

-- 
	Viktor.