Re: [TLS] TLS1.3

[[e-mail] (Martin Rex)]

Nikos Mavrogiannopoulos wrote:
>
> Peter Gutmann wrote:
> >
> >>Padding the plain text up to a multiple of the cipher block size (minus the
> >>hash size) ahead of doing the MAC is a more modest change that may be more
> >>widely applicable to existing cipher suites - with a "pad-then MAC" client
> >>hello
> >
> > That won't help against the current attack.
> 
> This family of attacks relies on the fact that padding isn't
> authenticated, i.e, you can play with it without being detected. If
> pad is part of the MAC there is no issue.

I agree with Nikos.

The problem of TLS is that it does not authenticate the entire
decryption output (i.e. uses MAC-pad-encrypt rather than pad-MAC-encrypt).


> 
> > The only proper fix for the
> > various attacks that target the encryption is to protect everything with the
> > MAC, i.e. switch to encrypt-then-MAC.  The definitive reference for this is
> > Hugo Krawczyk's "The Order of Encryption and Authentication for Protecting
> > Communications (Or: How Secure is SSL?)".


To me, Hugo's "proof" that AtE would have a "general weakness"
is misleading (and slightly bordering on lame).

He proofs a security problem *ONLY* for a MAC-extend-encrypt scheme,
and only under the condition of the availablility of a decryption oracle
that will blissfully answer a huge amount of chosen ciphertext attacks.

Potentially not realizing that the existing MAC-pad-encrypt approach
in SSL/TLS is one incarnation of the dangerous MAC-extend-encrypt schemes,
Hugo's paper incorrectly asserts this (last paragraph on page 3):

  The security of AtE with specific encryption modes.

  This paper does not bring just bad news. We also show that the
  authenticate-then-encrypt method is secure under two very common
  forms of encryption: CBC mode (with an underlying secure block cipher)
  and stream ciphers (that xor the data with a random or pseudorandom pad).
  We provide a (near optimal) quantified security analysis of these
  methods. While these positive results do not resolve the
  "generic weakness" of the authenticate-then-encrypt method
  (and of SSL), they do show that the common implementations currently
  in use do result in a secure channels protocol.


CBC-padding is simply an incarnation of "extend" in MAC-extend-encrypt.

And the addition of unauthenticated-but-encrypted information may allow
breaking the confidentiality of the cipher, given sufficient responses
from the decryption oracle, frobbing the ciphertext block covering the
unauthenticated part and getting the de-padding function to oracle
about characteristics of the resulting plaintext block.


> 
> Using encrypt-then-MAC to counter the attack is as radical change as
> using the GCM or CCM modes. This isn't a small fix, it is an upgrade
> which changes the protocol semantics (e.g. MAC is no longer encrypted
> - whatever that may mean). Moreover, encrypt-then-MAC isn't a panacea.
> There is nothing wrong with MAC-then-encrypt, it is TLS that applied
> it incorrectly by keeping the pad unauthenticated. I'd prefer a fix
> that keeps the current protocol semantics.


Personally, I also feel somewhat uncomfortable with a "radical" change
to encrypt-then-MAC rather than the simply using the obvious
pad-MAC-encrypt, as originally suggested by Serge Vaudenay.

When the encryption scheme that is used is bijective, then it will not
matter (to the confidentiality of the encryption) whether AtE or EtA
is used, as long as authentication covers the exact same information
in both cases, i.e. *ALL* of it, padding included.

However, in the EtA scheme, we would have a naked keyed hash.  And would
an attack on the keyed hash become somehow feasible, that attack might be
easier on a naked keyed hash than on an encrypted keyed hash.


-Martin