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

[Watson Ladd <[e-mail]>]

On Fri, Nov 29, 2013 at 3:22 PM, Nikos Mavrogiannopoulos
<[e-mail]> wrote:
> 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...
1/n-1 record splitting needs to be implemented anyway, thanks to the
installed base.
>
> 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.
The passive voice is doing a lot of work here. Bellare and Namparah
showed that EtA is generically secure,
AtE isn't. Rogaway sent out an email in 1995 pleading for EtA in TLS.
"no flaws known"!="proved to be secure"
AtE works only if the encryption and decryption functions are
bijective, as in stream cipher mode. Otherwise you have
an oracle. For CBC you restrict the message space to messages
multiples of the blocksize. But really, this is quibbling about
the color of a fence, rather than building it. Marsh Ray already
addressed these issues to the point where only the most blockheaded
would refuse to listen.

Furthermore, proliferating a mess of extensions and half-assed fixes
makes driving adoption of updates even harder.
The right to proceed is to provide something like a one round
protocol, that is secure, with no options, and sell adoption
on the new features. By making improved security contingent on TLS 1.2
adoption, we screwed ourselves over. But if what
results in a frankenprotocol on top of SSL 3.0, it might be better to
include a IM_OUTTA_HERE cipher which instructs the
recipient to do something sane instead.

Something needs to be done about the issues of TLS. It's clear there
is no consensus on this list, but doing nothing is not an option.
Personally, driving to TLS 1.2 avoids the need to deploy a long series
of patches, as well as design fixes and analyze them.
>
> regards,
> Nikos
Sincerely,
Watson Ladd
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin