[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.129.122.17 with SMTP id v17mr4722126ywc.67.1479923274528; Wed, 23 Nov 2016 09:47:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.115.3 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: https://github.com/tlswg/tls13-spec/pull/776/files 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 implementation). -- Colm
- [TLS] Additional warnings on 0-RTT data Colm MacCárthaigh
- Re: [TLS] Additional warnings on 0-RTT data Martin Thomson
- Re: [TLS] Additional warnings on 0-RTT data Colm MacCárthaigh
- Re: [TLS] Additional warnings on 0-RTT data Martin Thomson
- Re: [TLS] Additional warnings on 0-RTT data Colm MacCárthaigh
- Re: [TLS] Additional warnings on 0-RTT data Martin Thomson
- Re: [TLS] Additional warnings on 0-RTT data Colm MacCárthaigh
- Re: [TLS] Additional warnings on 0-RTT data Christian Huitema
- Re: [TLS] Additional warnings on 0-RTT data Colm MacCárthaigh