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

[Watson Ladd <[e-mail]>]

On Sun, Nov 10, 2013 at 12:28 PM, Michael D'Errico <[e-mail]> wrote:
> 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.
Who thinks this is a real problem? If the MAC is weak it shouldn't be used,
end of story. We have a real issue burning people now, and the
argument against it is
something that won't be an issue for a while, and only affects people
with their head in the
sand.
I say we publish 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?
No.
>
> Mike
>
Sincerely,
Watson Ladd
>
>
>
> 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
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin