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