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

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Mon, 23 March 2015 08:00 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 8BC6C1A8967 for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 01:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 E0EF9vjZD8P0 for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 01:00:02 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4C11A894C for <tls@ietf.org>; Mon, 23 Mar 2015 01:00:02 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 61C0B9010C; Mon, 23 Mar 2015 09:59:59 +0200 (EET)
Date: Mon, 23 Mar 2015 09:59:59 +0200
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Andrey Jivsov <crypto@brainhub.org>
Message-ID: <20150323075958.GA18876@LK-Perkele-VII>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com> <550F6582.9040602@brainhub.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <550F6582.9040602@brainhub.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/0a6ex6bkVucnjp8sKEY2wDm5skQ>
Cc: 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 08:00:05 -0000

On Sun, Mar 22, 2015 at 05:59:46PM -0700, Andrey Jivsov wrote:
> On 03/22/2015 02:49 PM, 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]
> >
> >Again, the attacker will need to mess with the TCP channel, but their
> >ability to do so is part of our basic threat model [RFC 3552].
> >
> >It's important to understand that this is a generic issue, not an
> >issue with TLS in particular, so it's not like there's some other
> >0-RTT model we can lift and put into TLS that would solve the problem.
> 
> The SessionID-like fallback is a problem for a "broadcast" of the single
> "POST /buy-something" (via a replay of a captured message). Had the Server 2
> above rejected the ClientHello [+0-RTT] which was intended for Server 1
> (orbit1), there would be no problem.

I think there would still be a problem: The transaction would get retried
(there might be a dialog to shift the blame on user).

I don't see a way of eliminating this "forking" attack without essentially
eliminating 0-RTT (since client doesn't prove that its exchange key was
correct until handshake is complete, and at that point you can start sending
data anyway).
 
> One way to solve this is to say that the server must *fail* 0-RTT, as
> opposed to fallback to 1-RTT, if the "orbit" indicated in the ClientHello is
> not that of this server.

Won't help, and in general, you really don't want to fail TLS handshake
unless you know the handshake with that client can never succeed (e.g.
not supporting secure enough crypto).

> The only requirement here is that the server always knows its orbit. Servers
> must have different orbit IDs if they cannot handle simultaneous receipt of
> identical "POST /buy-something".

As noted above, you can use server that has different orbit as the second
server in attack.

Heck, in above diagram, the second server actually _rejects_ the 0RTT.
You propose additionally rejecting the connection, which will get retried.

Heck, I think the "forking" attack might actually work better in practice
with servers with different orbit IDs than with the same orbit ID, since
the latter could actually signal that replay is happening to the client.


-Ilari