[TLS] TLSv1.3 Cookies

Matt Caswell <frodo@baggins.org> Wed, 13 September 2017 14:53 UTC

Return-Path: <frodo@baggins.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4FC132949 for <tls@ietfa.amsl.com>; Wed, 13 Sep 2017 07:53:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=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 NIwjsgU2XrN5 for <tls@ietfa.amsl.com>; Wed, 13 Sep 2017 07:53:50 -0700 (PDT)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [217.160.92.157]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28B6132DFB for <tls@ietf.org>; Wed, 13 Sep 2017 07:53:50 -0700 (PDT)
Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 0E1D35A8 for <tls@ietf.org>; Wed, 13 Sep 2017 15:53:48 +0100 (BST)
Received: by mail-it0-f41.google.com with SMTP id 6so2977275itl.1 for <tls@ietf.org>; Wed, 13 Sep 2017 07:53:48 -0700 (PDT)
X-Gm-Message-State: AHPjjUjgNPnKbE+sl2/4wOgokl6llXnKFabCERGMrk9IStPoc62n6+q2 oQVzeMsD3XARdpYd2Zfy8DGtE/Al9N2tgESEiiI=
X-Google-Smtp-Source: AOwi7QCxiBKQHi5SFlWPsKSVyIbQB1Wo2qESG+ynukiZVrkclIKvam6gPB/lidNZTvZofnyUOlztK30G7mHld22QhhM=
X-Received: by 10.36.23.88 with SMTP id 85mr4462946ith.86.1505314427424; Wed, 13 Sep 2017 07:53:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.165.25 with HTTP; Wed, 13 Sep 2017 07:53:46 -0700 (PDT)
From: Matt Caswell <frodo@baggins.org>
Date: Wed, 13 Sep 2017 15:53:46 +0100
X-Gmail-Original-Message-ID: <CAMoSCWYXWJMkFAdrcy033_bjMZjRUiU-V5f8MkoTXyvDfw+z6A@mail.gmail.com>
Message-ID: <CAMoSCWYXWJMkFAdrcy033_bjMZjRUiU-V5f8MkoTXyvDfw+z6A@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/QDW52ypi9RXdOpWX52kVNPCaRFI>
Subject: [TLS] TLSv1.3 Cookies
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 13 Sep 2017 14:53:52 -0000

I am looking at trying to implement the TLSv1.3 stateless cookie
mechanism (in order to be able to support QUIC stateless retries).

I am not clear how cookies are supposed to interact with early_data.
Consider the scenario where a server is operating statelessly. Because
there is no state each ClientHello looks like the first one it ever
saw. The server only knows that a particular ClientHello is actually a
ClientHello2 following an HRR because of the state held in the cookie.

What happens when a client attempts to send early data to such a
server? The server will process the ClientHello and determine that
there is no cookie, sends back an HRR and then forgets all of its
state and waits for the next ClientHello. However what it actually
gets next is early_data. It does not know that that early data
followed an earlier ClientHello (because it is stateless) so it does
not know to skip the records. It just looks like illegal records so,
presumably, it will respond with an alert.

Should a stateless server silently drop any records that it doesn't understand?

I am also unclear what protects against cookies being replayed. If an
attacker wishes to perform an amplification attack on a particular IP
it awaits a legitimate ClientHello with a cookie coming from that IP
and records it. It then replays that ClientHello with cookie to the
server many times. The cookie looks valid to the server and it
responds with its ServerHello, full Certificate chain etc back to the
original IP. What have I missed here?

Thanks

Matt