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

Roland Zink <roland@zinks.de> Mon, 23 March 2015 14:05 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 B4E7F1A8ABF for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 07:05:03 -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 PxBizhU85I_q for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 07:05:02 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) (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 C2E281A8AB3 for <tls@ietf.org>; Mon, 23 Mar 2015 07:05:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427119499; l=1909; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date; bh=gogSl4ADhreK6NIGxr+btJ4qwFMUObz36zYnY4eyqUA=; b=yH1R/DsYicFdE+rRF0eF4YmVq2F3exLAPBxrn7IXLn2dNSJq67TTm2yg5daQtNriI95 wouI5Fr6kLvgYoGiRQ/jLljZxJ3d9OjJApfYj5AEJ4y0jrgsEgHMRSdQi5Lsy3ait4p5I GK/w/K6tNt+HAP8JEaA9H8I9w3HXIbiodkg=
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 R00452r2NE4w5E1 (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 15:04:58 +0100 (CET)
Message-ID: <55101D8B.7050909@zinks.de>
Date: Mon, 23 Mar 2015 15:04:59 +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>
In-Reply-To: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/GWXsfqMek1lzHk4wZlSls_MUda4>
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 14:05:03 -0000

On 22.03.2015 22:49, Eric Rescorla wrote:
>
> There are a number of basic ways to address this issue, but I think
> the main plausible[0] ones are:
>
> 1. Keep the server state globally consistent and also temporally
>    consistent so that replays can always be detected.
>
> 2. Remove the TLS anti-replay guarantee for the data sent in the first
>    flight and tell applications to only send data there that can
>    tolerate being replayed.
>
The server probably can't trust the clients choice. An API on the server 
side is needed as well to check that data received on the first flight 
is acceptable.

> 3. Remove the TLS reliable delivery guarantee for the data sent in
>    the first flight, so that the stack doesn't automatically replay it.
>
What does happen when the stack can't deliver it? Is the user asked to 
replay? Does the software hang?

> The first of these options (global state) is possible, but only in
> some limited circumstances, namely very sophisticated operators and/or
> situations where there's really only one server which has good state
> management. An example of the latter is WebRTC, where the server can
> have a different anti-replay context for each connection.
>
> The other two options clearly require a separate API to handle this
> special first-flight data and would require applications to handle it
> separately. So, for instance, in option 2, you would have something
> like:
>
Does this mean a standard API will be specified. A separate API would 
mean that 0RTT will not be available in many cases because the replay / 
delivery guarantee requirements are unknown in some layers.

The solutions 2 and 3 seem to give the problem to the application, e.g. 
either the application doesn't (need to) care or need to implement it. 
So solution 1 seems the way to go although for non single server 
solutions this may be complicated.

Roland