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

[Michael D'Errico <[e-mail]>]

In trying to figure out what's stalling the encrypt-then-mac draft
I came across this old message (below).  The complaint against the
draft appears to be that since the MAC is no longer encrypted, there
may be a way to recover the secret HMAC key.  HMAC-MD5 is mentioned
as the problem, so I checked to see which cipher suites use it.

The 13 cipher suites using MD5 are:

   A     0001    TLS_RSA_WITH_NULL_MD5
   B     0003    TLS_RSA_EXPORT_WITH_RC4_40_MD5
   C     0004    TLS_RSA_WITH_RC4_128_MD5
   D     0006    TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
   E     0017    TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
   F     0018    TLS_DH_anon_WITH_RC4_128_MD5
   G     0022    TLS_KRB5_WITH_DES_CBC_MD5
   H     0023    TLS_KRB5_WITH_3DES_EDE_CBC_MD5
   I     0024    TLS_KRB5_WITH_RC4_128_MD5
   J     0025    TLS_KRB5_WITH_IDEA_CBC_MD5
   K     0029    TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
   L     002A    TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5
   M     002B    TLS_KRB5_EXPORT_WITH_RC4_40_MD5

Eight of these (A, B, D, E, G, K, L, and M) are considered trivially
breakable; F allows for a MitM; J uses the deprecated IDEA cipher;
and C and I use RC4 which we now know is completely broken.

That leaves only one cipher suite to possibly be concerned about:

   H     0023    TLS_KRB5_WITH_3DES_EDE_CBC_MD5

Do we really want to hold up the encrypt-then-mac draft any longer
because of this one Kerberos/triple-DES/MD5 cipher suite?

Mike




Nikos Mavrogiannopoulos wrote:
> On 09/08/2013 04:59 AM, Peter Saint-Andre wrote:
> 
>>> As I recall there were three proposals for resolving the padding
>>> bug in TLS
>>> 1.       An extension for Pad First (i.e. padding before an
>>> otherwise standard TLS mode of operation)
>>> 2.       An extension for Encrypt-then-MAC (i.e. this draft)
>>> 3.       The replacement of each existing cipher suite with an 
>>> equivalent AEAD one
>>> Was any consensus achieved as to the best approach?
>> I never saw further discussion on this topic. Are there I-Ds for each
>> approach? #3 seems onerous to me (and doubling the number of cipher
>> suites doesn't seem like a desirable outcome), and as far as I can
>> tell there's no specification for #1. Although I am not a TLS expert,
>> the Encrypt-then-MAC I-D referenced above seems reasonable, it neatly
>> solves a real-world problem, and we have running code; thus IMHO
>> formalization of this approach deserves to be considered in the WG.
> 
> It is important when trying to solve an issue not to introduce new
> issues. The current proposal for #2 unfortunately does not take into
> account known counter-measures for key recovery attacks in MACs (see [0]).
> 
> regards,
> Nikos
> 
> [0]. http://www.ietf.org/mail-archive/web/tls/current/msg09520.html