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

Colm MacCárthaigh <colm@allcosts.net> Mon, 23 March 2015 05:21 UTC

Return-Path: <colm@allcosts.net>
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 D6D9F1A8830 for <tls@ietfa.amsl.com>; Sun, 22 Mar 2015 22:21:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 U-lJnRk8tDu9 for <tls@ietfa.amsl.com>; Sun, 22 Mar 2015 22:21:03 -0700 (PDT)
Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573311A883E for <tls@ietf.org>; Sun, 22 Mar 2015 22:21:03 -0700 (PDT)
Received: by obbgg8 with SMTP id gg8so115388645obb.1 for <tls@ietf.org>; Sun, 22 Mar 2015 22:21:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5uYeR6B7U2ufvvU0JqXIV9RLdO2+Sohs6HtN6TcU5Zg=; b=HtS9tdSVecVrKtw3ahFewoP8ohVH99GlGGg9LEK+k2TEnTsIw9gMZBKMFquPLSQtpJ VdaAt5Vtqx54+w9ZXjfL/UAmHszpN2rzU4n+nzUJWwDetKeHGYIowLB2v2uDJLcZmrZ3 zmPEx231CwcIFycCLLFFMYzLKRCEOVInsYKEI/rCxt+afLut+9k4cEXlJQo2qq4lEme2 oEctch+N+4SD4A5YMq5aMxiXTIXcaU1afH+NsPdlzq1Gi2dVJ4vqxMBl0oLB1uca/Jxf 9Z56HCcco7Yl7Ewzaul/hmUmCP0+/xg8qt14ekQBflW44tkfQwOLVOYTyzomtjlo/Ytf DpfA==
X-Gm-Message-State: ALoCoQm0loAbTn2lB1MDJQqOAAYQzy5ULoMRVE+ntDKggl+MSsr4tJpl/wPLnEonTvwp6BDz0pvw
MIME-Version: 1.0
X-Received: by 10.182.133.68 with SMTP id pa4mr74095934obb.87.1427088062789; Sun, 22 Mar 2015 22:21:02 -0700 (PDT)
Received: by 10.76.129.235 with HTTP; Sun, 22 Mar 2015 22:21:02 -0700 (PDT)
In-Reply-To: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com>
Date: Sun, 22 Mar 2015 22:21:02 -0700
Message-ID: <CAAF6GDfuuWBaF1OZXn7hWVzJe_rqzsMqSy8N5ds_07qJk=yVEA@mail.gmail.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/b3-WEiggF9cEhiYMWF0a5-uDARM>
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:21:05 -0000

On Sun, Mar 22, 2015 at 2:49 PM, Eric Rescorla <ekr@rtfm.com>; wrote:
>
>
> A SOMEWHAT CONTRIVED ATTACK
> This is all fine so far, but the abstraction you probably want TLS to
> supply to the application is that the data it sends in the first
> flight isn't lost even in this case. In order to accomodate this, the
> natural design is for the TLS stack to retransmit the plaintext in the
> client's first flight as the first data it sends under the new keys.
>
> An attacker can make use of this as follows. When the client sends
> the initial first flight he captures the TCP connection and makes his
> own TCP connection to the server, forwarding the first flight.
>
> Client                        Attacker                          Server
>
> ClientHello [+0-RTT] ------------>
> "POST /buy-something" ----------->
>
>                               ClientHello [+0-RTT] --------------->
>                               "POST /buy-something" -------------->
>
>                                                    [Processes purchase]
>                                  <---------- ServerHello [accept 0-RTT]
>                                                   (+ rest of handshake)
>
>
> The attacker just discards the server's response and then the server
> somehow forces the server to reboot (this is the hard part).

It's probably easier than rebooting in a real-world attack: the server
is vulnerable to state exhaustion attacks. For a primitive server, an
attacker can generate enough client randoms to exhaust the state
capabilities of the remote end. A more complicated server set-up might
use a distributed store, sharded on the client random data; but even
if they pay enough attention to use a salted hash of the client random
data for the shard key, it only changes the attack effort by a linear
factor.

> 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.

This probably opens a can of worms; but I think schemes that involve
an assumption of roughly synchronized time between clients and servers
can go quite a way to mitigating replay attacks too.

Also, I know it's groan-worthy: but a safe variant of 0RTT is to first
transit data opaquely, protected by a key that is only sent once the
server is authenticated. This makes optimistic execution impossible on
the server side, but it does preserve some of the benefits of network
throughput and latency.

> I would expect them to have relatively similar impacts on the wire,
> namely applications would self-designate certain data as replay-safe
> (e.g., HTTP GETs) and would send it in the first flight and then
> either let the stack retransmit (option 2) or retransmit themselves
> (option 3). This isn't that odd, since, as AGL observes, browsers
> already routinely retry some HTTP requests that appear to fail even for
> ordinary TLS (i.e., no HTTP response was received) so in those cases
> they have already circumvented the anti-replay guarantees supplied by
> TLS, but of course that's different from having TLS give up those
> guarantees.

I don't think it's a good idea to use browsers as the comparison here.
TLS is used extensively outside of browsers and many of those
applications do not retry like this, and rely on TLS as their
anti-replay mechanism.

-- 
Colm