Re: [TLS] padding bug

[[e-mail] (Martin Rex)]

Hovav Shacham wrote:
> 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.

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.


> 
> I would prefer an approach that deprecates existing suites in favor of
> 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