[TLS] Additional warnings on 0-RTT data

Colm MacCárthaigh <colm@allcosts.net> Wed, 23 November 2016 17:49 UTC

Return-Path: <colm@allcosts.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9154512A1B4 for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 09:49:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yAKEm---no8S for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 09:49:37 -0800 (PST)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 7782712A1FF for <tls@ietf.org>; Wed, 23 Nov 2016 09:47:55 -0800 (PST)
Received: by mail-yw0-x236.google.com with SMTP id a10so17883105ywa.3 for <tls@ietf.org>; Wed, 23 Nov 2016 09:47:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=vic8M4MTETn6Fm/juHqnZyI4qsVMQ60sAm63L39y9OE=; b=ALfu5P4UPKWc+kyBZ4CFBfmLsF+zCgFS4i0yEpzgyzxKcI+AwcIYMNGievW2ertFEN eEKqFjb7SWtibqZ6AGzf/XXO+iYlhz/Wttz2YtR4yVR4EYWscjua4j4d9RLsDSqtw9Yy d2VXc2RaOkrJbuwMZxykjLYpFCHVyKG21PPLhtS5go2uE6g4qc0iNEB1S4w3GAx0l5ZN KrHr8VgSx3vSt+eHLQWKxnm/0LzOQi/ag6DkLVl2bLZichiKGEWbwaZnRbZnLFqR0IQ0 3HK0pTVWNGcrBShKLFjVq37G1wAf79fmwwmv2lYyR4/bsjNNlPibGMaQE2RJt5NnbTkw Fyag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vic8M4MTETn6Fm/juHqnZyI4qsVMQ60sAm63L39y9OE=; b=hNPdYykrnB3bMBfSo0Ve8dx5Js9Ro4T1VUduLV1Xwujuz9zzCQiGTlP6+jcixN/mCa AL2Tsg6DwBb3z4c4v3mRqvYjbTGH1OYoRhIKsn8j4mN+aZveMfnUGdhf0Eu4vRU6PcfI Wf+LVbl1dUyWXWBRQNsAQ2VSXMKMj67oWoNjUSamg+5VnuM1HQibdB9XT6E4kz/XJXa8 NaQY9eSENokmCzQe+gtoc7DwNGPLzem3oDgEQM14YLehTp/Rom4kHbPKJdgimm8CO9dE 6TQQkiH43xgHoHA/UvXesC1Yct0/ZfdWzDh8hi1GSJEfEcEAMB8jpb/tFsNDSHaugbKI 1SvQ==
X-Gm-Message-State: AKaTC00nVkswN77ur+4/QXEoM0zRubRK+R4/hkxyGFyHBAzYGXI9H7WMp7O3/0uXDdvKJrgSwD6oK6H6BX7Psg==
X-Received: by with SMTP id v17mr4722126ywc.67.1479923274528; Wed, 23 Nov 2016 09:47:54 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 23 Nov 2016 09:47:54 -0800 (PST)
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Wed, 23 Nov 2016 09:47:54 -0800
Message-ID: <CAAF6GDeAbbwnUaCGg4sVxzP6S3ECoQ2nzCi3FyB1gRV9mJHxGA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c07b4a01308770541fb7d22"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pv7hi1FWtJzC7ekhbMUl5daDys8>
Subject: [TLS] Additional warnings on 0-RTT data
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 23 Nov 2016 17:49:38 -0000

I've submitted a PR with an expanded warning on the dangers of 0-RTT data
for implementors:


The text is there, and the TLDR summary is basically that time-based
defenses aren't sufficient to mitigate idempotency bugs, so applications
need to be aware of the sharp edges and have a plan.  For clarity, I've
outlined three example security issues that could arise due to realistic
and straightforward, but naive, use of 0-RTT. There's been some light
discussion of each in person and on the list.

In the PR I'm "MUST"ing that applications need to include /some/ mitigation
for issues of this class (or else they are obviously insecure). In my
experience this class of issue is so pernicious, and easy to overlook, that
I'm also "RECOMMEND"ing that applications using Zero-RTT data
*intentionally* replay 0-RTT data non-deterministically, so as to keep
themselves honest.

At a bare minimum I think it would be good to make clear that clients and
implementations MAY intentionally replay 0-RTT data; to keep servers on
their toes. For example a browser could infrequently tack on a dummy
connection with repeated 0-RTT data, or an implementation could
periodically spoof a 0-RTT section to the application. That should never be
considered a bug. but a feature. (And to be clear: I want to do this in our