Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Colm MacCárthaigh <colm@allcosts.net> Mon, 14 March 2016 03:52 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 5252312D94A for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 20:52:01 -0700 (PDT)
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 xCmRavUrkW0v for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 20:51:59 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 65D2212D946 for <tls@ietf.org>; Sun, 13 Mar 2016 20:51:58 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id g127so153240666ywf.2 for <tls@ietf.org>; Sun, 13 Mar 2016 20:51:58 -0700 (PDT)
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:date:message-id:subject:from:to :cc; bh=rJRvNq1lSGRY2V9gRHRgiNKDnUuJQFXtS4XgB3LoExg=; b=J0xskfbfZGqlKn/7wPpJK9sDJ7nto+rbRFX6uCdUQMLXYqiNXULjBDlnepJl/nh3k0 buCrj4G+x+F1ky1c1LG8T+DT8BXQassT53JE7kifCCEAo/61278RoB56LGsYg9ohtK5m G+ieP87siiBUQQd47c9ks/QZ2eFNvq7YM2ILonSN4jL1LE0Yxni099xKOcBgTe2+bKzW WUAkwQ60vpOXp6cJPox4i6Z4Sd0+8nhV2vOKQyh96MEBL7vctreM1aQP+IwaMAZfwob/ /a4D6KVDunj+UXWhBT/yTsYLCvoPCUUEs8ZA97PfNxLG6mw+8sYh5wGwSmaPFhzdVJDb zXUg==
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:date :message-id:subject:from:to:cc; bh=rJRvNq1lSGRY2V9gRHRgiNKDnUuJQFXtS4XgB3LoExg=; b=eYI2N75bOpZjqDpk1X0Iixg3ByYo9upDHBFPutz+zIvVvInkSy0/dlLlT78Qbn1XhU T890w1cf5SP6RK4IkzdQ/x722T4CoWk4TuS6aDvEk5YWqhy8q98lCRvFhPtG7mkpHmbH y7/obY7PlgMMV19Lon4732Ti42m/WlmaeZflY1077M2vJnl/Jn/Tw99xCJBQMFcooq3k kVhLHlhMr8C5hySoEeaRtXtJsIOhyvaOL97HiYB0f/bgMwRcfp26uM0tAM5yVG5hSVGG uwU2PvWd6Piq3mZ7Q+u2iT6TV2LTdK6mYHePxyjrKPz0XKKv84Utz7PEXk1gczmb7fHj jpuw==
X-Gm-Message-State: AD7BkJK9ONRsnrp9o9tMoo91oI4cAm36BBD1UX7qmKPgmWvsDPy6LxKzNshn7qne/xUNa53N3FigakKSOu5r1Q==
MIME-Version: 1.0
X-Received: by 10.129.72.78 with SMTP id v75mr12069801ywa.78.1457927517481; Sun, 13 Mar 2016 20:51:57 -0700 (PDT)
Received: by 10.129.32.196 with HTTP; Sun, 13 Mar 2016 20:51:57 -0700 (PDT)
In-Reply-To: <56E54B85.4050204@cs.tcd.ie>
References: <56E54B85.4050204@cs.tcd.ie>
Date: Sun, 13 Mar 2016 20:51:57 -0700
Message-ID: <CAAF6GDeOFNgNt_+O=gkBedqP55qdnOpKKQ9-HOQ6i7fYpLanqw@mail.gmail.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=001a114dcb02c9e57d052dfa3323
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/6wPBD3nhzdKEiXM3XZXCx2xROOw>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe 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: Mon, 14 Mar 2016 03:52:01 -0000

On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>;
wrote:

> With 0rtt, I think it also becomes a dangerous
> implement. So, that's my personal opinion, while not wearing an
> AD hat.
>

+1 for this as 0RTT is outlined in the draft. But to expand a little:

* Losing forward secrecy for "GET" requests and user cookies seems like a
very bad privacy trade-off. Collection of wire data, combined with a bug or
an attack that could disclose the ECDH parameters, does not seem so far
fetched these days.

* I imagine that 0RTT data may be intended for pre-fetching hints, e.g.
"I'm request URL foo as user bar, so please get a start on fetching the
resources I need". That suggests trivial application-level "is the cache
warm" side channels, or "lets trash the whole cache" DOS attacks, would
both be common.

* A vast number of APIs build on top of TLS/HTTPS are not idempotent or
replay safe. Even carefully designed APIs may have subtle side effects such
as a user being charged for the request, or the request counting towards a
throttle of some kind. Even ones as silly as there go your 10 free nytimes
articles; or booting an opponent out of your less-than-friendly sudoku
tournament.

* The draft calls out that early data needs to be handled differently than
regular TLS data. This reminds me of the problems with renegotiatable
client authentication - similar to what Marsh Ray highlighted a long time
ago. What if a request or action spans both the early and the regular data
sections? what would a "safe" API look like, for an SSL/TLS library layer?

It seems like the benefits of of 0-RTT boil down to two things;

1. Increased throughput
2. Give the recipient a chance to a get a head-start on servicing some kind
of request.

For 1. Raw data throughput could be improved by envelope encrypting the
early data; and transferring the envelope key only once the session has
been fully authenticated. Not that interesting to most people; but works. I
can't think of a good way to achieve 2 without all of the problems that
have been mentioned.

At a minimum I'd suggest that the draft could not call it "data", but maybe
instead "hint"; and make it so that early_data and application_data are not
supposed to appear sequentially in a stream. E.g. someone calling TLSRead()
or whatever should never expect to see the early_data; it's a deliberate
and separate stream.

-- 
Colm