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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 13 March 2016 11:14 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 9F37B12D586 for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 04:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 UDPEAZCQ-f20 for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 04:14:20 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E346412D574 for <tls@ietf.org>; Sun, 13 Mar 2016 04:14:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 45EE0BE35 for <tls@ietf.org>; Sun, 13 Mar 2016 11:14:16 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbq5UtSOmr6T for <tls@ietf.org>; Sun, 13 Mar 2016 11:14:14 +0000 (GMT)
Received: from [10.87.48.75] (unknown [86.46.23.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C5D61BE32 for <tls@ietf.org>; Sun, 13 Mar 2016 11:14:13 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457867654; bh=49GVHUGQjFZyzDFdnIFDytQnTWTK+iT9Hdx9druON+Y=; h=To:From:Subject:Date:From; b=Aid5BxKEZWwcsHHHIha3GUZq46r50MBd9eRv1B5JyNn9/475/bc6akK3W4SNfZ3HU 3a+qcGDU/LpcaWvAknh5sQAqmMeO2QXxxsBzDrWuKvJoCl6cR4wYPHxhQKLimrhOq3 TtECJayordwmBY2FMjwrEvhCXn3spb0mMzRm7RbY=
To: "tls@ietf.org" <tls@ietf.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56E54B85.4050204@cs.tcd.ie>
Date: Sun, 13 Mar 2016 11:14:13 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050803060709070003030602"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/HWmYw_E6e3fannqW16uNv0hfJ2E>
Subject: [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: Sun, 13 Mar 2016 11:14:22 -0000

Hiya,

First, with no hats, if the WG were to have a poll on whether
or not to include 0rtt in TLS1.3, then as a participant in the
work here, I'd be firmly arguing to leave it out entirely. I
really think an over-emphasis on reducing latency for browsers
is going to bite us (and the Internet) in the ass in the same
ways that emphasising interop over security has in the past with
fallbacks to older, worse versions of TLS/SSL, with all their
inherent flaws and bits of e.g. crappy "export" crypto support.
Absent 0rtt, TLS1.3 seems to me to be an excellent step forward
in security. With 0rtt, I think it also becomes a dangerous
implement. So, that's my personal opinion, while not wearing an
AD hat.

However, if I'm in the rough about the above, (which seems
to me to be the case now) then my job as AD when I get a publication
request that includes 0rtt, will include figuring out if that's
safe or not. And I've no clue how I'll do that unless the WG
have already done some analysis of the many, many protocols
that use TLS. Note that I do not consider "use a different API"
to be a sufficient answer here (it is necessary, but not
sufficient). Given that there are 263 RFCs that reference RFC5246 [1]
and google scholar counts 2738 documents that cite RFC5246 [2] I'm
puzzled as to how we can know the consequences of adding that
dangerous implement to TLS1.3.

I've been worried about this for a while now, but the recant
thread started by Kyle Nekritz [3] prompted me to send this
as I think that's likely just the tip of an iceberg. E.g., I'd
be worried about cross-protocol attacks one might be able to
try with JS in a browser if the JS can create arbitrary HTTP
header fields which I think is the case. I'm also worried about
things like EAP-TLS and RADIUS/Diameter if used via TLS etc
where we don't necessarily have the right people active on this
list. While I don't have any concrete attacks, the ability to
create replayable data smells really really bad to me and I've
no idea how we can honestly be confident we've done a good job
on TLS1.3 while such smells linger.

I'd also note that my overall impression of the TRON w/s was that
researchers thought 1rtt was mostly ready, but that there was
no similar confidence in 0rtt. I also don't think "another TRON" is
the answer here, as we'd not have the right people in the room
who'd know the consequences of replay for all instances of <foo>/TLS.

Lastly, just in case: Note that I am not saying that I'll block
a publication request for TLS1.3 that includes 0rtt based on
my own technical opinion if I'm in the rough. I'm saying that I
have no idea how I'll do an AD evaluation of such a thing so
I need help from the WG in analysing the broader impact of 0rtt,
and if that's not done before the publication request, we'll have
to figure it out then. And that could be messy, if we make a
bunch of late discoveries that 0rtt creates issues for a bunch of
instances of <foo>/TLS1.3.

So, can people suggest ways in which we can figure out the impact
of replayable data across all the many uses of TLS?

Thanks,
S.

[1] http://www.arkko.com/tools/allstats/citations-rfc5246.html
[2]
https://scholar.google.com/scholar?q=http%3A%2F%2Fwww.hjp.at%2Fdoc%2Frfc%2Frfc5246.html&btnG=&hl=en&as_sdt=0%2C5
[3] https://mailarchive.ietf.org/arch/msg/tls/K-PmKrP6Df_qIVq_BTielgtQwUY