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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Tue, 2013-11-12 at 23:29 +0100, Martin Rex wrote:
> 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.

There are two options. (a) Minor changes to the application protocol
(for all application protocols), or (b) minor changes to the TLS
protocol. The draft above takes the latter approach.

I also don't understand what do you mean by heading TLSv1.2-only. The
proposal in the above draft works from SSL 3.0 to TLS 1.2. There is
nothing TLS 1.2-specific there.

> 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.

The above draft does:
1. prevent padding oracle attacks
2. hide the length of the plaintext

What you propose there is having the plaintext appear and finish in an
unpredictable position. That's an interesting approach, not handled by
the draft above.

In simple terms you're asking for more bells and whistles :)

regards,
Nikos