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

Eric Rescorla <ekr@rtfm.com> Sun, 22 March 2015 22:30 UTC

Return-Path: <ekr@rtfm.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 ED3D91A6F11 for <tls@ietfa.amsl.com>; Sun, 22 Mar 2015 15:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 UvuuEp0AToo9 for <tls@ietfa.amsl.com>; Sun, 22 Mar 2015 15:30:52 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 EB4B71A6F20 for <tls@ietf.org>; Sun, 22 Mar 2015 15:30:51 -0700 (PDT)
Received: by wixw10 with SMTP id w10so44419384wix.0 for <tls@ietf.org>; Sun, 22 Mar 2015 15:30:50 -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:from:date :message-id:subject:to:cc:content-type; bh=OhnNBejeScAHN+hvpbWO6E623o2ghYAXhZ/N+0umXxs=; b=LHxbeEI0iQmGOENEBtcBO0go/U0/ofdhHFL+1xQMlCHdmt3Og33xA2RW46PITX0xUr CaMRMNKJmR31GBzXfRuYpvxs/vdtkRZ9sBQ3tKuLZa9ZV7cAc/4U5LCYq1tI6ZGmagC2 CN6SON3iq0kZmIaro0pHdkEe7xyVUouc2HrcLTF4x1iPM/LMqXqGKmtXgIN2UwQyiHvh RnN+4KmWtfXkYmeXSv2jCNgmjD0pQrC373QMkYdjZLRwhU6a2WXCO5A3IwjGsc/vE2Py FHG/Kax8CwxAdpoR4pple9guFDtnqx+3Yz+RpxTkn/FayoOdufhbq4mD5llU/wLxFU2Q SdkA==
X-Gm-Message-State: ALoCoQnC9uneJyIahvdZDYegvOX1fGw2F2YQDYj+Anl1w1zJ2f4LkbugfYaaRYwoivgp9zM8rupD
X-Received: by 10.194.108.9 with SMTP id hg9mr183148072wjb.68.1427063450775; Sun, 22 Mar 2015 15:30:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.205.198 with HTTP; Sun, 22 Mar 2015 15:30:10 -0700 (PDT)
In-Reply-To: <CAOhHAXzkWSvLCnSPhH2TQZgC4r7j-wX8TzmZf0pGnvKw2_VFcQ@mail.gmail.com>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com> <CAOhHAXzkWSvLCnSPhH2TQZgC4r7j-wX8TzmZf0pGnvKw2_VFcQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 22 Mar 2015 15:30:10 -0700
Message-ID: <CABcZeBOAuraUEHbi1c1qJuBhZMgkSfx1ukB4ihtabNRE73KVRQ@mail.gmail.com>
To: Mohamad Badra <mbadra@gmail.com>
Content-Type: multipart/alternative; boundary="047d7bf10b1c0e361b0511e81ad5"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/PVI4ogil81n20QPYEAPwEBCQGjY>
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: Sun, 22 Mar 2015 22:30:54 -0000

On Sun, Mar 22, 2015 at 3:26 PM, Mohamad Badra <mbadra@gmail.com> wrote:

> Hi Eric,
>
>
>> 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).
>>
>> Once the server has rebooted, the attacker re-sends the client's
>> initial flight then just forwards data back and forth to the client.
>>
>> Client                        Attacker                          Server
>>                               ClientHello [+0-RTT] --------------->
>>                               "POST /buy-something" -------------->
>>
>>    <--------------------------------------  ServerHello [reject 0-RTT]
>>                                                  (+ rest of handshake)
>>
>> Finished --------------------------------------------------------->
>> "Post /buy-something" -------------------------------------------->
>>                                                   [Processes purchase]
>>
>> At this point, you've mounted a successful replay attack. Obviously
>> this is not that great an attack because it requires you to be able to
>> force a reboot and also get in under the client's timeout window.
>>
>
>
> According to draft-rescorla-tls13-new-flows-01:
>
>    The EncryptedExtensions MUST include an ART indicator that matches
>    the client's ART so that the client knows that the 0-RTT handshake
>    was successful and that the client's application_data was accepted.
>
>
>
> I wonder why the Server doesn't include an indicator in his reject
> (encrypted indicator) so the client will avoid sending its request again.
>

This would basically be option #3, namely that this data is unreliable.

Best,
-Ekr

(BTW, based on what a server can reject after a reboot)
>
> Best regards
> Mohamad
>