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

[[e-mail] (Martin Rex)]

Nikos Mavrogiannopoulos wrote:
> Martin Rex <[e-mail]> wrote:
>> Personally, I would really prefer to _not_ move the MAC outside
>> of the encryption, i.e. leave it as pad-mac-encrypt like Serge Vaudenay
>> originally recommended.  In particular, keeping the hands off the
>> GenericStreamCipher PDU processing.
> 
> I prefer this approach too, so I've taken the parts from the
> length-hiding draft and moved them to a draft that simply describes a
> new padding approach to solve the padding oracles. In any case I still
> believe that something needs to be done about that, whether it is
> pad-encrypt-then-mac or pad-mac-then-encrypt.
> 
> http://tools.ietf.org/html/draft-mavrogiannopoulos-new-tls-padding-00

This is a whole new extension adding bells and whistles, not a fix to
any existing issues, and appears to be heading for TLSv1.2-only.

Padding with arbitrary length is something that every application
could do with every TLS implementation already in the installed base
and every existing cipher suite, no changes to TLS necessary,
requiring only minor changes of the application protocol.


I would really like to see a _simple_ TLS extension that fixes the two
CBC issues for the GenericBlockCipher PDU for *ALL* versions of TLS
including SSLv3, making _all_ protocol versions use the same
GenericblockCipher PDU format again (the way this should have been
done in 2003).


You proposal adds the padding at the beginning only.  Since the
problem exhibited by RC4 is inherent to any XOR-encryption with
a pseudo-random-pad, AES-CCM, AES-GCM, etc. I would make such an
extension use random fraction, random content, authenticated padding
on both sides of the plaintext, with a combined minimum padding length of
at least 16 bytes, in order to mitigate statistical attacks on
any bias that may be found in the pseudo-random-pad.

But that is just an idea for what could be done if I had lots of free
time and nothing else important to do.


Seeing how slowly TLSv1.2(rfc5246) and TLS renegotiation extension (rfc5746)
are adopted by the installed base, I'm currently more interessted in
small changes and fixes to TLS that address real issues of the installed
base, such as interoperability problems (such as DHE parameter negotiation
and TLS protocol version intolerance and rsa premaster version goofs)
and weaknesses (published and unpublished).


-Martin