[TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted)

Watson Ladd <watsonbladd@gmail.com> Fri, 18 March 2016 14:40 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C77D912D81A for <tls@ietfa.amsl.com>; Fri, 18 Mar 2016 07:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UjLB-raIqR4o for <tls@ietfa.amsl.com>; Fri, 18 Mar 2016 07:40:08 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 28C9612D918 for <tls@ietf.org>; Fri, 18 Mar 2016 07:39:02 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id k1so143903638vkb.0 for <tls@ietf.org>; Fri, 18 Mar 2016 07:39:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=sxB+RtS5rJc757hhcvZJ+Dp6Xx3k2hqzoniDPhnxjJ8=; b=dAlmK1Ds/cYsSgF05PrvJgEqeBhLSHMDOJ7tuCGrvmT+y0HvGB0wobC4dbhaO90BWI e8Vfpq31jkHGA2J2vrebNfwL4aNgWqaMRL4VkazPTcwhyvKU6U89NMgcsni/x1Ejjw0i S7+YrkapRfvdwGmwBMx8GWWSdMuVL8p53lP2k52xoy8x7F5S7NyEQy+5eIpEOLSHZrNz IW81n1azOGsnIMGfjXQ2OqHQGYKUPionUO2dyWQsGxN9kUdXMLFZO7q6kjyCRDItM9RV /Q9bx8qCicdpJf2BRbBgABKRJHr9YYsFrtHSrKr4tbp5TbrqI7FO4eOefwYIlc16oKzC 3ZPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=sxB+RtS5rJc757hhcvZJ+Dp6Xx3k2hqzoniDPhnxjJ8=; b=i2A4lJgjSsTwQ8NFwSFx1vhZzvtgA4IL/7vH7Z3VwJCMvBXgKD0Tjz0eFBwiPMs547 2r7vlgv6+aCuTUMtCub3/tdXqILsTo3z5VCr6rz/PJ2VXOENZi9ZcHr1DybtHqm/4Jva tkq7lZiJUEn8blZPcDc0JHKwwRkNKjDNJEn0u0HIF5YAbQ5EYA2IrGJr7wgwkwKRHqez n+QwiqMjxgoPaoaUowGZ3y0we1kKw1ar0hR0AHCGEk/9NuWNOrpmuKstOtOA1lHuA7at JbSGDK/u1RegDi3KLbW2h6HdUObucxNGvfrx5HlWAqOFLBw+Pf7uLi2qEq2pU9YqQ7a0 NVzg==
X-Gm-Message-State: AD7BkJKTig9xO6f8tXXm61jjiq5ZFqrApU4uI8WwTSfRD+pG7RQJKDMV3GRldIyLEwuKHnxwZ13AZn3bzsQF+A==
MIME-Version: 1.0
X-Received: by with SMTP id 190mr17624420vkk.51.1458311941119; Fri, 18 Mar 2016 07:39:01 -0700 (PDT)
Received: by with HTTP; Fri, 18 Mar 2016 07:39:01 -0700 (PDT)
Date: Fri, 18 Mar 2016 07:39:01 -0700
Message-ID: <CACsn0c=r7m94xOg0T=sxXn0JMfDq0us2iuEWi29uFEgE+r4SLw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/uupdJ-BBOeA3stYv7goQjGTVaNA>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: [TLS] History of TLS analysis (was Re: 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: Fri, 18 Mar 2016 14:40:11 -0000

On Fri, Mar 18, 2016 at 1:57 AM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:
> Watson Ladd <watsonbladd@gmail.com> writes:
>>As written supporting this draft requires adopting the encrypt-then-MAC
>>extension. But there already is a widely implemented secure way to use MACs
>>in TLS: AES-GCM.
> This is there as an option if you want it.  Since it offers no length hiding,
> it's completely unacceptable to some users, for example one protocol uses TLS
> to communicate monitoring commands to remote gear, they're very short and
> fixed-length, different for each command, so if you use GCM you may as well be
> sending plaintext.  In addition GCM is incredibly brittle, get the IV handling
> wrong and you get a complete, catastrophic loss of both integrity and
> confidentiality.  The worst that happens with CBC, even with a complete abuse
> like using an all-zero IV, is that you drop back to ECB mode.

Then use a padding extension that solves all problems, instead of
relying on a side effect of CBC mode. Why do we want this to look
different from TLS, instead of a subset of widely deployed things ala

Furthermore, GCM only requires adding a counter for each packet, which
you have to do anyway. If you want, specify GCM-SIV.
>>Likewise, this draft modifies the way the master secret is computed, despite
>>a widely implemented different solution to the problem, namely the EMS triple
>>handshake fix.
> Firstly, that solves an entirely different problem, and secondly I don't
> recall ever seeing EMS support in any embedded device, it may be widely
> implemented in Windows and OpenSSL but I don't know how much further it goes.

What is your master secret change solving? I don't see how EMS is
solving an entirely different problem, but maybe that's because I
don't understand what your change is solving.

>>The use of uncompressed points makes off-curve attacks much easier than with
>>compressed points.
> Everything uses uncompressed points at the moment without any problems, and
> compressed points are patented.

At RWC 2016 one of the presentations decrypted connections to a server
by exploiting off-curve point attacks. Your draft claims that
verifying signatures before sending will address an ECC security
threat. I don't see what threat that addresses, and there is a much
worse one that is left unaddressed, namely off-curve point attacks. We
should mandate no reuse of ephemerals to help with that.

>>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more extensively
>>analyzed then TLS 1.2.
> As the rationale points out, the mechanisms in SSL were also very heavily
> analysed when they were released.  It didn't protect the protocol from 20
> years of subsequent attacks, which we've leared about over those 20 years of
> implementation and deployment experience.  With TLS 1.3 we have zero
> implementation and deployment experience.  Do you really believe there will
> never be any attacks on it after it's rolled out?

Deployment does not affect the protocol's amenability to analysis, or
the degree of analysis it should receive. The actual history of TLS
1.2 and earlier analysis shows that many of the vaunted "attacks" are
the result of old publications being dusted off, due to the anemic
response of the security industry to the attacks, and that there's an
actual body of knowledge

The use of predictable IVs in TLS 1.0 was first commented on by
Rogaway in 1995. (I'm hunting down the source, but this is from a
presentation of Patterson) That should have immediately resulted in a
protocol change but didn't. Did it really take 20 years to realize
this was a problem? Or was it 20 years of ignoring the problem until

In 1998 Bleichenbacher noted that PKCS 1.5 encryption is dangerous.
TLS could use much better simpler designs which hash the ciphertext
and plaintext together, but didn't. Today we still haven't killed a
nearly 20 year old attack.

That TLS doesn't sign enough when using DH was an observation made in
2004. Sadly I don't recall who did it. It wasn't fixed over two
revisions, and culminates in Logjam. Did this require deployment to be

Lastly, it's the primitives but the protocol that is the proper unit
of analysis. With TLS 1.3 we have a symbolic model and have a
considerable amount of examination of the cryptographic security. That
should give far more confidence than 20 years of being run: computers
don't analyse the protocols they run.

> Peter.

"Man is born free, but everywhere he is in chains".