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

[[e-mail] (Martin Rex)]

Juho Vähä-Herttua wrote:
> 
> [e-mail] (Martin Rex) wrote:
> > 
> > I'm from the "don't-fix-it-if-it-ain't-broken" camp.
> > And the less code needs to be changed to adopt some useful feature,
> > the more likely you will see it being adopted for patches/maintenance.
> > I have seen *ZERO* compelling reason for switching to encrypt-then-mac
> > in TLS.  And I'm not aware of *ANY* reason why we should touch/change
> > the GenericStreamCipher processing (which Peter's proposal does).
> 
> I'm trying to explain my reasoning.  First of all HMACs are designed
> to authenticate data safely, but encrypting them adds an unknown
> factor to the calculation.  Why not just use them as they are
> supposed to be used.

There is nothing "unknown" about encryption, and certainly it will not
dillute the MAC (unless you come up with a bogus encryption scheme that
is not bijective--i.e. expands the data during encryption.

Keep in mind that encrypted MAC is what SSL&TLS have always been doing,
and what a number of implementations will continue to be doing for many
years to come.

If this had been the other way round, i.e. SSLv3 and TLS had been using
encrypt-then-mac, then I would not be asking to change it _unless_
a _real_ problem was demonstrated, and for the very same reasons
(don't fix it if it ain't broken, smaller code changes are more likely
to get adopted during maintenance).


> 
> For me it is much more intuitive to do pad-encrypt-mac compared to attack
> resistant pad-mac-encrypt. In current TLS spec you can give the
> plaintext+HMAC to the encryptor as is and let it handle the padding.

In current TLS, you pass the plaintext to the record layer, and the
record layer will pipe it thorugh the compression function and
pass it to the pad+mac+encrypt function.

>
> The same is true for encrypt-then-mac, just give the plaintext to the
> encryptor (either CBC or stream) and let it handle the padding.
> But in pad-mac-encrypt you have to know the length of the MAC before
> you actually calculate the MAC and add it manually! This is counter
> intuitive.

Actually, in TLS you have to _know_ the size of the MAC long before you
process the first record, because it is part of the Connection state:

  http://tools.ietf.org/html/rfc2246#section-6.1

   MAC algorithm
       An algorithm to be used for message authentication. This
       specification includes the size of the hash which is returned by
       the MAC algorithm.

Since compression algorithms other than the null compression will
usually have an output size different from the plaintext input size,
the size of the mac and the exact amount of padding is something
internal to the TLS record layer.  The caller above the record
layer doesn't need to know and doesn't need to care.


> 
> Finally, encrypt-then-mac allows detection of tampering in an earlier
> stage, which is a plus in my books.

This is entirely irrelevant in the real world (for TLS).
You have to successfully go through a full TLS handshake before you can
mess around here, and the public key stuff during the full handshake
is so much harder on the honest server, that this is a lame argument.


> 
> > The fact that GHASH must be encrypted is sufficient proof that an
> > encrypted MAC provides a better safety margin than a plaintext MAC.
> 
> I don't think GHASH behaviour proves anything about HMACs,
> but please prove me wrong.

It does.  Why do you think that HMAC is better than a simple keyed hash?
because it doesn't make the output of the keyed hash directly accessible
to the attacker.  This immediately transcends from the definition of HMAC,

  http://tools.ietf.org/html/rfc2104#section-2

  H(K XOR opad, H(K XOR ipad, text))

and the rationale behind HMAC:

  http://tools.ietf.org/html/rfc2104#section-6

   6. Security

   The security of the message authentication mechanism presented here
   depends on cryptographic properties of the hash function H: the
   resistance to collision finding (limited to the case where the
   initial value is secret and random, and where the output of the
   function is not explicitly available to the attacker)

The "output of the function that is not explicitly available to the attacker"
is the output of the inner Hash function of the HMAC function.

It has the exact same output size as the output of the outer hash function.
Under given the assumption that H is "collision resistant", the outer
Hash-function of HMAC is equivalent to a symmetric encryption of
a block cipher with the blocksize of the hash size and the key "K".

Encrypting this the HMAC output again with a symmetric block cipher
is not going to weaken the resulting strength, but may strengthen it
when the properties of H are not as good as one might like.


> 
> > MAC in the clear is only safe when the MAC algorithm is sufficiently
> > close to perfect.  We know painfully well that our hash algorithms
> > are *not* perfect, so I'm against taking chances, in particular
> > for the GenericBlockCipher PDU.
> 
> But in a VERY hypothetical case where attacks to some HMAC is found,
> we would have no idea how it affects TLS without further analysis,
> using it in a standard way would at least give more information about
> what is broken. And of course HMAC is not just a hash.

The security of HMAC is vitally dependent on the security of the underlying
hash function.

IIRC, The first weakness demonstrated for MD5 (by Dobbertin) were
modifications of two bits that cancelled each other out for a
specific internal state of the MD5 hash.  Later, methods were discovered
to compute two plaintexts that will have the same hash result for
arbitrary internal state.

What would be devastating for pad-encrypt-hmac is when a method was found
to find bit modifications that cancel each other out with little or no
dependence on the internal state of the hash.  This would immediately
and seriously affect all pad-encrypt-hmac schemes with that hash, the AEAD
and GenericStreamCipher schemes independent of encrypt-mac or mac-encrypt.

GenericBlockCipher with pad-mac-encrypt will be significantly less
impacted, because flipping specific bits on the plaintext (the data
that is mac'ed in pad-mac-encrypt) will only be possible if the
BlockCipher is broken as well.


-Martin