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

[[e-mail] (Martin Rex)]

Paterson, Kenny wrote:
> 
> "Martin Rex" <[e-mail]> wrote:
> >
> >The MAC provides integrity protection, the Encryption provides
> >confidentiality.  The quality of the MAC has exactly Zero impact
> >on the confidentiality provided by the Encryption.
> 
> The MAC is also necessary to preserve confidentiality in the face
> of active attacks.

That is a contortion of reality.  The MAC does not preserve anything
here.  The purpose of the MAC in communication protocols is to
mitigate the reaction/behaviour of the recipient of the communication
to become an oracle that can be polled quickly, repeatedly and often
to reveal fractions of bits of information that can be accumulated
by an attacker into disclosure of bytes of assumed confidential data.


> 
> If you need an example, consider the security history of IPsec's
> encryption-only modes. (Am I allowed to mention IPsec on a TLS list?
> Well, I just did.) 

The few things that I looked at were simple consequences of obviously
flawed assumptions, i.e. providing an oracle to the attacker and
no mechanism to stop an attacker from polling the oracle and learning.


Cryptographic algorithms have specific properties, and so do protocols
employing cryptographic algorithms.  Silently assuming that certain
properties will exist by accident/chance, rather than by explicit
design, is somewhat naive.  While it has been finally spelled
out in rfc5246 (TLSv1.2):

  http://tools.ietf.org/html/rfc5246#page-16

   Any protocol designed for use over TLS must be carefully designed to
   deal with all possible attacks against it.  As a practical matter,
   this means that the protocol designer must be aware of what security
   properties TLS does and does not provide and cannot safely rely on
   the latter.

a lot of consumers just don't get it.  They want to continue using
TLS as a magic pixie dust that provides universal security.


> 
> And, as far as I know, there are no significant attacks when IPsec is
> configured in encrypt-then-MAC configurations (e.g. ESP conf+auth or ESP
> followed by AH). On the other hand, all the configurations of IPsec where
> the MAC is applied before the encryption are broken. (Another
> demonstration that MAC-then-encrypt is not a robust choice.)


It is formally provable that MAC-then-encrypt for the existing symmetric
ciphers is at least as safe as encrypt-then-MAC.  The problem is, that
this applies only to _real_  MAC-then-encrypt, not to
any MAC-then-ExtendAndOtherStuff-then-Encrypt schemes that have
been used in IPsec and TLS, and are still being used in CMS|S/Mime
and WSSecurity, where additional unauthenticated data (e.g. padding)
is added after the MAC and before encryption, and where the recipient
will be offering a public decryption oracle.


> 
> >For EtA, the characteristics&quality of the Cipher do not affect
> >(and therefore can not improve) the quality of the MAC scheme
> >at all.
> 
> That's true but irrelevant, unless you don't trust your MAC algorithm. So
> why do you not trust HMAC-SHA256?

This isn't about the best-case scenarios, but about worst case scenarios,
i.e. HMAC-MD5.  The GHASH of AES-GCM by itself is weaker than HMAC-MD5,
but by being encrypted, the attacker can not take advantage of this.
An encrypted MAC will never be weaker than a plaintext MAC, but a
plaintext MAC may be turn out to be a weakness/vulnerability.


> 
> >Look at AES-GCM (NIST SP800-38D).  They use an efficient keyed has GHASH,
> >that does not have cryptographic hash properties (2nd paragraph Page 10):
> >
> >  http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
> >
> >  GHASH is a keyed hash function but not, on its own, a cryptographic
> >  hash function. This Recommendation only approves GHASH for use within
> >  the context of GCM.
> >
> >The use of GHASH without cryptographic protection would not be safe.
> >
> 
> Also true. But guess what? In GCM, the GHASH MAC is computed on the
> ciphertext!

The point is, that the AES-GCM MAC _is_ encrypted, and sending it
unencrypted would not be a good idea.


>
> The GHASH output is then encrypted using a further invocation
> of the block cipher. Where does this leave your argument in favour of
> MAC-then-encrypt?

The MAC in TLS'es GenericBlockCipher ought to be left encrypted.
And to make code changes small, efficient and managable, going
from mac-pad-encrypt to pad-mac-encrypt, as Serge Vaudenay suggested,
is IMO the most reasonable way forward.


-Martin