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

[[e-mail] (Martin Rex)]

Nikos Mavrogiannopoulos wrote:
> > > 
> > > http://tools.ietf.org/html/draft-mavrogiannopoulos-new-tls-padding-00
> 
> 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.

Personally, I prefer to seperate true fixes
(such as changing mac-pad-encrypt -> pad-mac-encrypt) from
new features.


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

The AES-CCM and AES-GCM specs take the extreme position that everything
that refers to GenericAEADCipher PDU must be TLSv1.2 exclusively.

I would very much welcome if we could kill this, and let implementors
use GenericAEADCipher with whatever TLS version they see fit.
Such a relaxation should be negotiated, though, to avoid confusion
(and interop problems) with excessively pedantic implementations
that follow obviously flawed suggestions in immature specifications.


> 
> > 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 :)

If you can't be good, at least be good at it.  :)

If you want to retrofit random padding into TLS (and into the stream and
aead cipher PDUs specifically), then you could at least try to mitigate
the most obvious problems with XOR-encryption schemes: the problems with
biases/patterns in the pseudo-random-pad and the possibility to accurately
flip individual bits in the plaintext.


-Martin