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

Roland Zink <roland@zinks.de> Mon, 23 March 2015 16:08 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 251D01AC3DF for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 09:08:19 -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 gQ0VbO2j9iYR for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 09:08:18 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (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 D28151A92B6 for <tls@ietf.org>; Mon, 23 Mar 2015 09:08:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427126895; l=1809; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date; bh=WohEgxlf2jQgeXI+jq3DiXY1aeskyVAGzA4VRzkoE0M=; b=qmOPMhXUUkt5txrGUzmHzuYYaTRh1E8OAxJv9HZ11FdUiOQp4UVMXdkdAiPV5NgGJ7T saEwQu53TorHuPKRT87hMZRpxC8QmosGGoh8D0VhNYxzDhwp0yfgfZz0Hx32akbrqaSru sCM1x1wVdIL+i/FzOrJOcu6wVppdbAac/K8=
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 204104r2NG8C6SO (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 17:08:12 +0100 (CET)
Message-ID: <55103A6E.4060409@zinks.de>
Date: Mon, 23 Mar 2015 17:08:14 +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> <55102E3A.70300@zinks.de> <20150323152831.GG9387@mournblade.imrryr.org>
In-Reply-To: <20150323152831.GG9387@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/9uXkooEONrI-dYM3CrPmbFNFzWM>
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 16:08:19 -0000

On 23.03.2015 16:28, Viktor Dukhovni wrote:
> 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.
Seem like very limited use, but still when somebody builds something on 
top of such a stack not knowing that something special needs to be done. 
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.
>>>> 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.
>
Well DNS is only an example anyway. Assuming the server is returning A,B 
on even requests and B,A on odd requests and an attacker replays all 
requests then the server will always returning the same result to the 
real clients.