Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 20 March 2016 11:09 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 7CCC612D6A3 for <tls@ietfa.amsl.com>; Sun, 20 Mar 2016 04:09:53 -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 mGp6diDs6qUz for <tls@ietfa.amsl.com>; Sun, 20 Mar 2016 04:09:50 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id BE89D12D656 for <tls@ietf.org>; Sun, 20 Mar 2016 04:09:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id C1B0123F9; Sun, 20 Mar 2016 13:09:48 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id zryDKbturM94; Sun, 20 Mar 2016 13:09:47 +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-smtp3.welho.com (Postfix) with ESMTPSA id AB0F12310; Sun, 20 Mar 2016 13:09:47 +0200 (EET)
Date: Sun, 20 Mar 2016 13:09:45 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Message-ID: <20160320110945.GA30544@LK-Perkele-V2.elisa-laajakaista.fi>
References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <201603191930.35445.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C27783@uxcn10-tdc05.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C27783@uxcn10-tdc05.UoA.auckland.ac.nz>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/895mdBdAC5gUCF6OkzsDcUX31tE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
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, 20 Mar 2016 11:09:53 -0000

On Sun, Mar 20, 2016 at 06:36:09AM +0000, Peter Gutmann wrote:
> Dave Garrett <davemgarrett@gmail.com> writes:
> 
> >It would be a lot simpler, safer, and interoperable to just mandate use of
> >the Extended Master Secret Extension [RFC 7627].
> >
> >https://tools.ietf.org/html/rfc7627
> 
> Yeah, in hindsight it makes more sense, I'll update the draft, although the
> update may not get in before the IETF freeze.  I was trying to avoid having to
> run two parallel hashing operations throughout the handshake (the other one
> being for the Finished message), but EMS is just a much more comprehensive
> solution (like EtM, it's one of those things where you think "why wasn't this
> added to TLS years ago") even if it means running two lots of hashing.

Well, if you have suitable implementation for it, the hash in EMS is over
prefix of what hash in Finished is over (so if you can finalize multiple
times, you can get away with just one computation).


Also, TLS 1.2 ServerKeyExchange signature is not taken over ClientHello
and ServerHello. This was famously exploited for FREAK and LOGJAM (and
then there is the DHE vs. ECDHE issue). Sadly, this was found out too late
for changing EMS extension to extend the signature.


Then there is the problem that DHE parameter sizes are not negotiated.
This is severe enough problem that it renders DHE effecively unusable
in some contexts[1][2].


And if you want ciphers that are actually not fragile, look at various
MRAE algorithms, not generic composition of CBC mode with HMAC (I have
seen even cryptographers get the latter wrong).



[1] TLS 1.3 doesn't completely fix this: Even if TLS 1.3 itself has
negotiated DHE parameter sizes, there is nothing preventing down-
negotiation to TLS 1.2, followed by server dumping some bad para-
meter sizes (forcing client to either break connection or being vuln-
erable to downgrade attacks).

[2] If you wonder why Chrome is deprecating DHE, it is exactly this
problem.



-Ilari