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

Roland Zink <roland@zinks.de> Mon, 23 March 2015 15:16 UTC

Return-Path: <roland@zinks.de>
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 B82DB1A9024 for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 08:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35] 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 KvTFwYJDe_aB for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 08:16:15 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927851A902E for <tls@ietf.org>; Mon, 23 Mar 2015 08:16:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427123770; l=1251; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date; bh=NHfwACmfhUVn/5433pbgh5N8Gx1otlFKyPPyDs1LNlU=; b=nJt9TKMoiYd20Uwg2OV8V3q0DLRbxLFNT5efe/Lzh2WqtVVjevWlpTslg/OR24MPCGh QJZJBlo2n4d19JtcoEc4lMWhMkeiLp8sESsrNDhQlxD7kJJlKp+W6XUyZrGM+JKkZvfPH lkedpz4jOccgxxf/g3xKwwWG17S5dUHNFUc=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLzTv5UXpfUT3myN2hlbG+UDaVCoSA==
X-RZG-CLASS-ID: mo00
Received: from [IPv6:2001:4dd0:ff67:0:b430:a134:91bc:ebfa] ([2001:4dd0:ff67:0:b430:a134:91bc:ebfa]) by smtp.strato.de (RZmta 37.4 AUTH) with ESMTPSA id 505eb0r2NFG863B (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256)) (Client did not present a certificate) for <tls@ietf.org>; Mon, 23 Mar 2015 16:16:08 +0100 (CET)
Message-ID: <55102E3A.70300@zinks.de>
Date: Mon, 23 Mar 2015 16:16:10 +0100
From: Roland Zink <roland@zinks.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: tls@ietf.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>
In-Reply-To: <20150323144052.GF9387@mournblade.imrryr.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/w5PdXrF6sbJhP4WzZC-_hd3mA-M>
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 15:16:16 -0000

On 23.03.2015 15:40, Viktor Dukhovni wrote:
> On Mon, Mar 23, 2015 at 03:33:09AM -0500, Nico Williams wrote:
>
>> 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.
Often there is a whole software stack on top of TLS. You probably can't 
forward the requirements through the complete software stack.
>>
>> 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.