Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

[Nikos Mavrogiannopoulos <[e-mail]>]

On Fri, 2013-11-29 at 23:38 +0200, Juho Vähä-Herttua wrote:

> > I also dislike (a) making a change to SSLv3/TLSv1.0
> GenericBlockCipher > processing, but (b) leaving the predictable IV
> exploited by BEAST > unfixed, and essentially creating two seperate new
> GenericBlockCipher PDUs, > rather than just a single one for all that
> fixes all known problems.
> 
> Ok, this is a valid point I have missed in the discussion. TLSv1.1 is a
> very small update to TLSv1, so one could always ask why is it not
> supported better. Is the version number change somehow scary to people?

At the time of TLS 1.1, it was not known that a big number of TLS
implementations were not able to properly do TLS version negotiation and
handle gracefully a TLS version downgrade. In gnutls after we added TLS
1.1 we realized that enabling it would make the library unable to talk
to several (prominent at the time) servers. So I presume that this
compatibility issue and the fact that there was no popular demand (which
occurred only after the media hype with the beast attack), very few
bothered to implement it.

> That being said, I would support adding explicit IV to the
> encrypt-then-mac spec, unless we have reason to think it would slow
> down adoption. Personally I don't see how a block of random numbers
> would be too difficult.
> 
> Nikos, do you think you should combine the pad and the IV in the
> defined structs? It would fix the BEAST attack at the same time even in
> SSLv3...

Certainly the draft (or any other fix) could require that the TLS 1.1
explicit IV in CBC ciphersuites is used when used with TLS 1.0 or
earlier (although, that would make the protocol messier, it looks it
provides quite some advantages).

> > MAC in the clear is only safe when the MAC algorithm is sufficiently
> > close to perfect.  We know painfully well that our hash algorithms >
> are *not* perfect, so I'm against taking chances, in particular > for
> the GenericBlockCipher PDU.
> But in a VERY hypothetical case where attacks to some HMAC is found, we
> would have no idea how it affects TLS without further analysis, using
> it in a standard way would at least give more information about what is
> broken. And of course HMAC is not just a hash.

Contrary to popular opinion on this list AtE is a standard way of
operation with no flaws known unless used with an unauthenticated pad
(as in TLS). When SSL 3.0 was designed AtE was believed to be the
conservative approach comparing to EtA.

regards,
Nikos