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

Nico Williams <nico@cryptonector.com> Mon, 23 March 2015 05:39 UTC

Return-Path: <nico@cryptonector.com>
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 208501A8850 for <tls@ietfa.amsl.com>; Sun, 22 Mar 2015 22:39:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 r645qTnXimiH for <tls@ietfa.amsl.com>; Sun, 22 Mar 2015 22:39:48 -0700 (PDT)
Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 52CBF1A883E for <tls@ietf.org>; Sun, 22 Mar 2015 22:39:48 -0700 (PDT)
Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id E63FA2005D909; Sun, 22 Mar 2015 22:39:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=FRZydb0nk+nKs2 vVzbnFJCRv4Bw=; b=PiMN8JC0CwbmmIUdRmsuAyIP2C5vMmtHU8GREPcPVmohHu YBrnpbCkr0plFqRJ8bsQ2HEI08+kxaHkbuxKAKV8SjH9jaWSj0vuBi6k9kxsEVTQ MkVsAVeDmZ8YhIlsZrd+frxJkn0efQgboID9+0R6XtlnYlqray54fQsHQszCA=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPA id A601C2005D903; Sun, 22 Mar 2015 22:39:47 -0700 (PDT)
Date: Mon, 23 Mar 2015 00:38:05 -0500
From: Nico Williams <nico@cryptonector.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20150323053804.GK21267@localhost>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/G7ucab47uu68Kgdlc542jVVpfbY>
Cc: "tls@ietf.org" <tls@ietf.org>
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 05:39:49 -0000

On Sun, Mar 22, 2015 at 02:49:28PM -0700, Eric Rescorla wrote:
> A MORE REALISTIC ATTACK
> During the interim meeting, DKG observed that you could produce the
> same "I've forgotten my state" situation if you have a distributed
> server. Say that the server operates in two loosely-synchronized
> data centers. In that case, you can get the following situation
> (shown without the attacker's intervention because of ASCII art
> limitation
> 
>  Client             Attacker            Server1              Server 2
> 
> ClientHello [+0-RTT] -->
> "POST /buy-something" ->
> 
>                     ClientHello [+0-RTT] -->
>                     "POST /buy-something" ->
> 
>                                         [Processes
>                                          purchase]
> 
> 
> 
>                     ClientHello [+0-RTT] ----------------------->
>                     "POST /buy-something" ---------------------->
> 
> 
>    <--------------------------------------  ServerHello [reject 0-RTT]
>                                                  (+ rest of handshake)
> 
> Finished --------------------------------------------------------->
> "Post /buy-something" -------------------------------------------->
>                                                   [Processes purchase]

If the client's first message had a nonce that the reject message (or
subsequent handshake) could authenticate, then this attack goes away
because the client will see that its message has been played, therefore
the client should not play it again.  Now the client application needs a
way to recover other than repeating the request!  It needs to go check
the status of whatever it wanted done (a GET, here).

Nico
--