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

Roland Zink <> Mon, 23 March 2015 15:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B82DB1A9024 for <>; Mon, 23 Mar 2015 08:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.65
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KvTFwYJDe_aB for <>; Mon, 23 Mar 2015 08:16:15 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 927851A902E for <>; 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;; 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=
Received: from [IPv6:2001:4dd0:ff67:0:b430:a134:91bc:ebfa] ([2001:4dd0:ff67:0:b430:a134:91bc:ebfa]) by (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 <>; Mon, 23 Mar 2015 16:16:08 +0100 (CET)
Message-ID: <>
Date: Mon, 23 Mar 2015 16:16:10 +0100
From: Roland Zink <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
References: <> <> <> <> <20150323083308.GL21267@localhost> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [TLS] 0-RTT and Anti-Replay
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.