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

Colm MacCárthaigh <> Mon, 14 March 2016 03:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5252312D94A for <>; Sun, 13 Mar 2016 20:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xCmRavUrkW0v for <>; Sun, 13 Mar 2016 20:51:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65D2212D946 for <>; Sun, 13 Mar 2016 20:51:58 -0700 (PDT)
Received: by with SMTP id g127so153240666ywf.2 for <>; Sun, 13 Mar 2016 20:51:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id v75mr12069801ywa.78.1457927517481; Sun, 13 Mar 2016 20:51:57 -0700 (PDT)
Received: by with HTTP; Sun, 13 Mar 2016 20:51:57 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Sun, 13 Mar 2016 20:51:57 -0700
Message-ID: <>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <>
To: Stephen Farrell <>
Content-Type: multipart/alternative; boundary=001a114dcb02c9e57d052dfa3323
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Mar 2016 03:52:01 -0000

On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell <>

> 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

* 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.