Re: [TLS] Additional warnings on 0-RTT data
Colm MacCárthaigh <colm@allcosts.net> Thu, 24 November 2016 02:18 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 75C7F129651 for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 18:18:54 -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 LSRE8kzjQMjL for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 18:18:50 -0800 (PST)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 5F86C129663 for <tls@ietf.org>; Wed, 23 Nov 2016 18:18:50 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id t125so27669566ywc.1 for <tls@ietf.org>; Wed, 23 Nov 2016 18:18:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BVksZDZhk0vRhfLO60WRBYZw+Lh9PRGe5ybRhkEKx+Y=; b=SXxQxTnhe4NAnOAhFSljBE9bOX2ZC8MIUTcJBQDGm7Jv4VtE9j4bZPIx6NPc3ULIfy U4k0ZD+7DwrF253gKRl3W+/70Q4rOj30sBy/W4E3Rs8sHOK5Zm2kTBx0p4wGgwu1CUv4 9l8CDsUimWoa91+oeBvHdsYKxgnZ+vbN82aYGsNx3FBNdFzkc4SGidE9duzwCx2MnDrX RHqY8kBtvmwznqZ64YZlfIRJxXRlZaYnhBja8hiH7UQnpzrxg0Cdhbbvo0UsZnqtYQfG 7q+fZC+BQ9sKy3qbMTs3GmyWobvJIp9ouKhZOkBGbDrWURRhP6tmdBG7Dn2YhQPqSq6k n7XA==
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; bh=BVksZDZhk0vRhfLO60WRBYZw+Lh9PRGe5ybRhkEKx+Y=; b=dvkz4e8yN5Fd3V6aZFE1MkO8t40OPo02Ki9o175hFvZEbG213tnoyPC5HLrMS2cG8O aBNcD8XdEW49xRToFVjBWeuGBpvK5cgDnhy1epP3RqBNeTPMi5Dy3IhfuAksqB9gHbCN xE7bmdeUd8/ETwOxaxaMIU8AcQEVaHgLiwEAxtQkzWn1f82CQhki41rIkE9r6A/00Jm7 bQ3fi+vGzMZNv+eeI1avPsnlUwKCPxGoymVXXgWDB79xL1uMakiqsbgf2JOWE1Z7mrDx 0FS2Vsh2IuGO9uT9muypdRtr+z0OjxUT2eAiCCJ+AqpWqBOtMYRAVeVU/NpK8bpBAEJ1 xT3Q==
X-Gm-Message-State: AKaTC01WKmNQMqg0dvrrEtPXmvVImyfBoUHKZPxvinK1A/EKnCv+yfyHnGbv8DY+/aeMcnF8lYg97PVUydXQ+g==
X-Received: by 10.13.217.9 with SMTP id b9mr61279ywe.44.1479953929511; Wed, 23 Nov 2016 18:18:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.115.3 with HTTP; Wed, 23 Nov 2016 18:18:49 -0800 (PST)
In-Reply-To: <CABkgnnXuL9jE04omz3n4FRWBKuJtpEV-bS2tSVvN7AJhW_4GUA@mail.gmail.com>
References: <CAAF6GDeAbbwnUaCGg4sVxzP6S3ECoQ2nzCi3FyB1gRV9mJHxGA@mail.gmail.com> <CABkgnnXuL9jE04omz3n4FRWBKuJtpEV-bS2tSVvN7AJhW_4GUA@mail.gmail.com>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Wed, 23 Nov 2016 18:18:49 -0800
Message-ID: <CAAF6GDcbJm7YWmUZ66JK9hUbU+Gt_-ERmjWxz9YnJe2KCtru-g@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="001a114fac3240d2a1054202a064"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/z7TEEYeQNOYkdEuvDbG2AoFnRNM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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: Thu, 24 Nov 2016 02:18:54 -0000
On Wed, Nov 23, 2016 at 3:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > This seems like too much text to me. Maybe some people would > appreciate the reminder that replay might cause side-effects to be > triggered multiple times, or that side effects are just effects and > those might also be observable. But I think that those reminders > could be provided far more succinctly. > My main goal is clarity, especially to application builders. In my experience the implications of replay-ability are frequently overlooked and it's well worth being abundantly clear. For most builders, those full implications have never occurred to them (why would they?), so it's often not a reminder, but new knowledge. It warrants a big warning label, not FUD, but honestly scary because it is a very hard problem. But still, the text can most likely be shortened some, edits welcome. > The bit that concerns me most is the recommendation to intentionally > replay early data. Given that I expect that a deployment that enables > 0-RTT will tolerate some amount of side-effects globally, and that > excessive 0-RTT will trigger DoS measures, all you are doing is > removing some of the safety margin those services operate with Can I break this into two parts then? First, do you agree that it would be legitimate for a client, or an implementation (library), to deliberately replay 0-RTT data? E.g. browsers and TLS libraries MAY implement this as a safety mechanism, to enforce and audit the server's and application's ability to handle the challenges of replay-ability correctly. At a bare minimum I want to be free to include this in our implementation of TLS, and in the clients that we use. I think there's value in explicitly documenting this, and that the problem is squarely on the server side if it is not replay-even-within-time-window-tolerant. Frankly: I want to be able to point to the spec and it be clear whose fault it is. Now second, consider a web service API that exists today and is using TLS. Many such APIs depend entirely on TLS for all anti-replay protection (though for the record, the SigV4 authentication mechanism we use at AWS includes its own anti-replay measure). When TLS1.3 comes along it is *very* tempting for providers to turn it on and use it for those APIs. Everyone always wants everything to be faster, and it won't be a huge code change. The problems of replay attacks could be dismissed as unlikely and left unaddressed, as security issues often are. So through a very predictable set of circumstances, I think those calls will be left vulnerable to replay issues and TLS1.3 will absolutely degrade security in these cases. What I'm suggesting is that we RECOMMEND a systematic defense: clients and/or implementations should intentionally generate duplicate data, so that the problem *has* to be addressed at least in some measure by providers. I far prefer that they be forced to encounter a low grade of errors early in their testing than to leave a large hole looming for users to fall into. This style of "Always always test the attack case in production" is also just a good practice that keeps anti-bodies strong. Thanks for reading and the feedback. On 24 November 2016 at 04:47, Colm MacCárthaigh <colm@allcosts.net> wrote: > > > > 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 mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > -- 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