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

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 13 March 2016 18:23 UTC

Return-Path: <ilariliusvaara@welho.com>
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 E2E7612D745 for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 11:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 iyWCz051SYO3 for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 11:23:40 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3B59612D740 for <tls@ietf.org>; Sun, 13 Mar 2016 11:23:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id DD9AB25D9; Sun, 13 Mar 2016 20:23:37 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id eR2yYIL9Tok3; Sun, 13 Mar 2016 20:23:37 +0200 (EET)
Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 97C7421C; Sun, 13 Mar 2016 20:23:37 +0200 (EET)
Date: Sun, 13 Mar 2016 20:23:36 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <20160313182336.GA13172@LK-Perkele-V2.elisa-laajakaista.fi>
References: <56E54B85.4050204@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <56E54B85.4050204@cs.tcd.ie>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/SngCoxq4jqm4x2f0M6I0BGTcEf0>
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: Sun, 13 Mar 2016 18:23:43 -0000

On Sun, Mar 13, 2016 at 11:14:13AM +0000, Stephen Farrell wrote:
> 
> 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.

Also, it occurs to me that problems can arise if one tries to
combine 0-RTT data with ALPN. The 0-RTT datablock is probably
only appropriate for one of the protocols...

If it is HTTP/2 vs. HTTP/1.1, if you get it wrong, the connection
will break (the HTTP/2 prelude). Wonder if one is so fortunate with
some other protocol pairs...

Hmm... That got me some ideas...

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

TLS 1.3 1-RTT is just boring, unless you are trying to do something
at least a bit screwy, like mix pure-PSK and client-auth.
 
No such luck with 0-RTT. There is all sorts of cryptographic screwyness
in there too (through getting rid of DH-0RTT should eliminate that).


Also, it occurs to me that very few protocols are even nearly as
vulernable to these kind of issues than HTTP, including cases where
one end is speaking HTTP but the other is not...



-Ilari