Subject: Re: [TLS] padding bug

From: Hovav Shacham <[email-masked]>
Date: Tue, 24 Sep 2013 09:31:26 -0700

Peter Gutmann <pgut001 at cs.auckland.ac.nz> writes:

It seems to be accepted by everyone except the WG chairs

I'm not thrilled with making changes to a fundamental part of the TLS
design through an extension.  TLS is too complicated to analyze already;
this doesn't help.

I would prefer an approach that deprecates existing suites in favor of
non-CBC authenticated encryption modes.

-hs.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 24 Sep 2013 12:40:30 -0400

On Sep 24, 2013, at 12:31 , Hovav Shacham <[email-masked]> wrote:

> I'm not thrilled with making changes to a fundamental part of the TLS design through an extension.  TLS is too complicated to analyze already; this doesn't help.
> 
> I would prefer an approach that deprecates existing suites in favor of non-CBC authenticated encryption modes.

I concur. Deprecate old, and require authenticated encryption.

---

From: [email-masked] (Martin Rex)
Date: Tue, 24 Sep 2013 19:15:54 +0200 (CEST)

> design through an extension.  TLS is too complicated to analyze already;

Where I agree is that it would be preferable to limit any fix
to the exact problem that has been identified (already by Vaudenay),
which is in how SSLv3&TLS use a Blockcipher in CBC mode
with "authenticate-pad-encrypt" rather than "pad-authenticate-encrypt".

"Making changes to a fundamental part of the TLS design through an
 extension" is a lame argument.  If this was really an issue, then we
would have to recomment against the existing rfc4492 approach to
the use of lliptic curve crypto in TLS in its entirety.

When we're concerned about the reconnect-fallbacks in Browsers
to an extension-less SSLv3 Clienthello--which btw. will currently
also prohibit the client to offer any AES-GCM cipher suites,
then we could define a signaling cipher suite for the
CBC-fix that can be safely included even in SSLv2 CLIENT-HELLO.

> non-CBC authenticated encryption modes.

This sounds like a marketeers approach to the problem, appreciating
the "new business opportunities".  But it is very ignorant about
software maintenance (for those vendors, which actually provide
maintenance), where the amount of code changes to the installed
base decides whether there is going to be an update produced
for the installed base.

There is nothing wrong with CBC, and it is a real pity that TLSv1.1
addressed&fixed only the running-IV problem, but entirely ignored
the authenticate-pad-encrypt that Vaudenay had explicitly described
as another problem.

What is available in Browsers is really just a small part of the problem.
For many communication scenarios, the end-to-end principle no longer applies,
and the distance between an end-users browser and the regional perimeter
gateway of the service provider is small in comparison to the distance
from the regional perimeter gateway (a reverse proxy for HTTP-over-TLS)
to the central/backend servers.  The end user has no knowledge and no
control what gets used behind the reverse proxy, and why should NSA try
to listen to the regional and short connection between a browser and
a regional gateway when it can instead pick up the contents on the regional
gateway, on the backend, or from the transnational connection in between,
an independent of whether that access is voluntary, compulsory or
surreptitious.

-Martin

---

From: Andrei Popov <[email-masked]>
Date: Tue, 24 Sep 2013 17:40:59 +0000

I agree that an approach that deprecates known weak ciphers in favor of (currently deemed to be) strong ciphers is preferable. This is how the TLS protocol was designed to remain secure over time, and it does not rely on new, optional extensions.

Besides, has someone completed a thorough analysis of all existing TLS ciphers when used within the proposed "Encrypt-then-MAC" construction?

Cheers,

Andrei

From: [email-masked] [mailto:[email-masked]] On Behalf Of Blumenthal, Uri - 0558 - MITLL
Sent: Tuesday, September 24, 2013 9:41 AM
To: Hovav Shacham
Cc: [email-masked]
Subject: Re: [TLS] padding bug

On Sep 24, 2013, at 12:31 , Hovav Shacham <[email-masked]<mailto:[email-masked]>> wrote:

Peter Gutmann <pgut001 at cs.auckland.ac.nz<http://cs.auckland.ac.nz/>> writes:
It seems to be accepted by everyone except the WG chairs

---

From: Ben Laurie <[email-masked]>
Date: Tue, 24 Sep 2013 18:46:30 +0100

On 24 September 2013 17:31, Hovav Shacham <[email-masked]> wrote:
> I'm not thrilled with making changes to a fundamental part of the TLS design
> through an extension.  TLS is too complicated to analyze already; this
> doesn't help.
>

That means requiring TLS 1.2, which is a far more complex update to
existing s/w than this change.