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

From: Watson Ladd <[email-masked]>
Date: Fri, 18 Mar 2016 07:39:01 -0700

On Fri, Mar 18, 2016 at 1:57 AM, Peter Gutmann
<[email-masked]> wrote:
> Watson Ladd <[email-masked]> 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
UTA?

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
exploitation?

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
observed?

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.

Sincerely,
Watson
> Peter.

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

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 18 Mar 2016 23:31:25 +0000

Watson Ladd <[email-masked]> writes:

>Then use a padding extension that solves all problems, instead of relying on
>a side effect of CBC mode. 

It's not a "side-effect of CBC mode", CBC mode allows padding packets, GCM
doesn't, see Colm MacCárthaigh's recent post on the topic.

>Why do we want this to look different from TLS, instead of a subset of widely
>deployed things ala UTA?

CBC mode ciphers have been part of TLS since SSL 2.0 (AFAIK) in 1994, I don't
know if SSL2 allowed for packet padding but 3.0 certainly did, so it's hardly
a major change.

>What is your master secret change solving?

Preventing manipulation of DH/ECDH parameters.

>Your draft claims that verifying signatures before sending will address an
>ECC security threat. I don't see what threat that addresses

The fact that ECC algorithms are extremely vulnerable to fault attacks, and a
single faulty signature can leak the private key, at which point its game
over.

I don't really know how to say the following without it sounding like an ad
hominem attack, but how much do you really know about real-world deployment
issues for this stuff?  You seem to be arguing for all sorts of personal
preferences based on, I dunno, abstract theorising, but you appear to be
totally unaware of actual real-world issues.  What I'm trying to figure out
is, how seriously am I supposed to take your comments?  Do you actually have
any real-world deployment experience with using this stuff in the field?

Peter.

---

From: Yuhong Bao <[email-masked]>
Date: Fri, 18 Mar 2016 17:12:54 -0700

> revisions, and culminates in Logjam. Did this require deployment to be
Don't forget how OpenSSL disabled the stronger EXPORT1024 ciphersuites in 2006 too.

Yuhong Bao

---

From: Watson Ladd <[email-masked]>
Date: Sat, 19 Mar 2016 07:51:00 -0700

> doesn't, see Colm MacCárthaigh's recent post on the topic.

GnuTLS is the only implementation that pads to more than 16 byte boundaries
> know if SSL2 allowed for packet padding but 3.0 certainly did, so it's hardly

It's not the CBC modes that's the change, but the EtM extension.
> Preventing manipulation of DH/ECDH parameters.

It's not immediately clear that it does so correctly. All data that
affects the interpretation must be in the master secret, and I think
that includes some data you haven't yet hashed. EMS we know gets this
right.
> single faulty signature can leak the private key, at which point its game

The same fault attack commonly works on embedded implementations for
ECDH. Except here the attacker just sends a point off the curve,
instead of inducing a fault in the signature routine. RSA signatures
with CRT optimization (commonly used on embedded devices) is also
vulnerable to similar fault attacks. I'm really not sure why you're
ignoring wrong-curve attacks on cached ephemerals: just add a
recommendation to not cache ephemerals.

> any real-world deployment experience with using this stuff in the field?

Given that I'm proposing subsetting what existing implementations
already do, instead of implementing new extensions, I find it
remarkable you're arguing that my proposal is harder to deploy. As for
what I know, I'm listed in the release notes of several TLS
implementations.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 21 Mar 2016 10:24:35 +0100

On Sat, 2016-03-19 at 07:51 -0700, Watson Ladd wrote:
> > > relying on

This is no longer true. We disabled that feature few years ago since it
was the main cause for several compatibility failures. The failures
were with other broken implementations, but no-one cares who is at
fault if the session doesn't work.

regards,
Nikos

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 21 Mar 2016 10:57:46 +0100

Watson Ladd <[email-masked]>:

> presentation of Patterson)

I think you mean
http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt,
which discussed the problem of predictable IVs in the context of work
towards IPSEC, without making the connection to SSL.  Note that this was
before TLS 1.0 and, I think, before SSL 3.0.  SSL 2.0 already had
predictable CBC IVs but placed the MAC before the payload in the
to-be-encrypted data, which, through sheer luck, avoided the problem.

Bodo