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

["Paterson, Kenny" <[e-mail]>]

Michael,

I posted on this back in September
(http://www.ietf.org/mail-archive/web/tls/current/msg09824.html). Let me
restate what I wrote then:

"I briefly reviewed the literature for the state-of-the-art on attacks
against HMAC-H for hash algorithm "H". (See for example
http://www.di.ens.fr/~fouque/pub/crypto07b.pdf, and later papers by L.
Wang et al. at Eurocrypt 2008, by X. Wang et al. at Eurocrypt 2009, plus
more recent work, e.g. Peyrin et al. at Asiacrypt 2012.)

In TLS, we essentially have H = MD5, SHA-1 or SHA-256.  In view of the
literature, of these, I'd recommend deprecating MD5 as the hash if
Approach #2 were to be adopted: current attacks do not seriously threaten
it, but taking a fairly conservative approach seems appropriate here."



To summarise: the currently known attacks on MD5 do not have significant
consequences for the security of HMAC-MD5 in the TLS context.

So the issue you raise should not be holding things up.

Cheers

Kenny 


On 10/11/2013 20:33, "Watson Ladd" <[e-mail]> wrote:

>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
>_______________________________________________
>TLS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls
>