Subject: Re: [TLS] TLS1.3

From: "Lewis, Nick" <[email-masked]>
Date: Mon, 11 Feb 2013 08:45:05 +0000

>> There is nothing wrong with MAC-then-encrypt,

>
> I disagree. The paper by Bellare and Namprempre from Asiacrypt 2000
> and Hugo Krawczyk's paper from Crypto 2001 both demonstrate good
> reasons to be suspicious of MAC-then-encrypt from a theoretical
> perspective.

The focus of this work was showing that a secure crypt and secure mac could be combined in such a way that the combination was insecure unless Encrypt-then-Mac were used. The reality of TLS though is that there are many MACs in everyday use that are not secure (based on hashes of 80bits or even 64 bits). These are currently protected from attack by being behind strong (112bit or 128 bit) crypt. Flipping round crypt and mac for all of TLS would expose these currently "good enough" cipher suites and result in further bad press from collision attacks.

I would be more comfortable with a pre-padding fix for the side-channel attacks (via a TLS extension) and then leave any decisions on flipping of the crypt and mac to a cipher suite by cipher suite basis when porting each to the aead api

-- Nick

The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 11 Feb 2013 09:26:40 +0000

Nick,

>  The reality of TLS though is that there are many MACs in everyday use that are not secure (based on hashes of 80bits or even 64 bits). These are currently protected from attack by being behind strong (112bit or 128 bit) crypt. 

The "usual" MAC algorithms for TLS are HMAC-MD5, HMAC-SHA-1 and HMAC-SHA-256 (HMAC-SHA-384 is also a possibility). These all have MAC tags of at least 128 bits.

RFC 6066 standardises "truncated" MAC tags for TLS, but these are known to be dangerous when used in combination with TLS's variable length padding (see the distinguishing attack in my Asiacrypt 2011 paper with Ristenpart and Shrimpton).

However, I was not aware of anyone actually using these truncated MAC tags, or any other short-output MAC algorithms in TLS. 

Can you provide specific examples in support of your argument?

Thanks,

Kenny

---

From: "Lewis, Nick" <[email-masked]>
Date: Mon, 11 Feb 2013 10:03:14 +0000

>> The reality of TLS though is that there are many MACs in everyday use that are not secure (based on hashes of 80bits or even 64 bits).
>> These are currently protected from attack by being behind strong (112bit or 128 bit) crypt.
>> The "usual" MAC algorithms for TLS are HMAC-MD5, HMAC-SHA-1 and HMAC-SHA-256 (HMAC-SHA-384 is also a possibility).
>> These all have MAC tags of at least 128 bits.

>RFC 6066 standardises "truncated" MAC tags for TLS, but these are known to be dangerous when used in combination with TLS's variable length padding
>(see the distinguishing attack in my Asiacrypt 2011 paper with Ristenpart and Shrimpton).

Sorry I meant to say "bits of security" (as in a birthday attack) rather than leave an impression of bit length
According to NIST HMAC-MD5 and HMAC-SHA-1 are vulnerable and should not be used hence forth
http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf

-- Nick

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 11 Feb 2013 10:15:05 +0000

Nick,

I think you've mis-read the NIST document.

SHA-1 is still "acceptable" for applications not related to digital signature generation (see Table 9). That includes MACing - see HMAC entry, Table 10, and the ensuing text:

"HMAC Generation: Any approved hash function may be used.
The use of key lengths ≥ 80 bits, but < 112 bits is acceptable through December 31, 2010.
From January 1, 2011 through December 31, 2013, the use of key lengths ≥ 80 bits, but < 112 bits is deprecated.
After December 31, 2013, key lengths < 112 bits shall not be used.
The use of key lengths ≥ 112 bits is acceptable."

For the definition of acceptable, the document says:

"Acceptable is used to mean that the algorithm and key length is safe to use; no security risk is currently known."

Regards,

Kenny

On 11 Feb 2013, at 10:03, Lewis, Nick wrote:

-- Nick

---

From: Yoav Nir <[email-masked]>
Date: Mon, 11 Feb 2013 10:18:29 +0000

On Feb 11, 2013, at 12:03 PM, "Lewis, Nick" <[email-masked]<mailto:[email-masked]>> wrote:

That's using SHA-1 as a signature hash.  As for other uses (emphasis theirs):

SHA-1 for non-digital signature applications:

For all other hash function applications, the use of SHA-1 is acceptable. The other applications include HMAC, Key Derivation Functions (KDFs), Random Number Generation (RNGs and RBGs), and hash-only applications (e.g., hashing passwords and using SHA-1 to compute a checksum, such as the approved integrity technique specified in Section 4.6.1 of [FIPS 140-2]).

---

From: "Lewis, Nick" <[email-masked]>
Date: Mon, 11 Feb 2013 10:39:24 +0000

>SHA-1 is still "acceptable" for applications not related to digital signature generation (see Table 9).

Oops Sorry I forgot that the boundary is "greater than or equal to" the 112bit security of SHA-1 rather than just "greater than"
(It looks as if NSS have until 2030 before they need to support TLS1.2 with HMAC-SHA256)

-- Nick

---

From: "Lewis, Nick" <[email-masked]>
Date: Mon, 11 Feb 2013 10:48:23 +0000

Uh? Can some one help me here?
SHA-1 has 80 bit of security according to B.2 and according to Table 9 an HMAC of 80 bits cannot be used but elsewhere the NIST document states that HMAC-SHA1 is acceptable

-- Nick

---

From: Yoav Nir <[email-masked]>
Date: Mon, 11 Feb 2013 11:02:07 +0000

A naive attack to find collisions in SHA-1 would require hashing 2^80 buffers. Another way of saying this is that is has 80-bit strength in collision resistance. In fact it's weaker than that, because there are more efficient attacks.

However, having a 2^80 or 2^64 collision attack does not make it any easier to find a second pre-image or to break HMAC-SHA-1. The HMAC construction is specifically aimed at preventing collision weakness from affecting MAC strength. You can read about this in section 6 of RFC 2104 or the references from there. 

Hope this helps

Yoav

On Feb 11, 2013, at 12:48 PM, "Lewis, Nick" <[email-masked]>
 wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
> Email secured by Check Point

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 11 Feb 2013 16:14:40 +0100

> The "usual" MAC algorithms for TLS are HMAC-MD5, HMAC-SHA-1 and HMAC-SHA-256 (HMAC-SHA-384 is also a possibility). These all have MAC tags of at least 128 bits.

Indeed but note that today we have key recovery attacks on HMAC-MD4
[1,0]. Partial key recovery attacks exist on HMAC-MD5, too. It may be
long until such an attack applies to an encrypt-then-authenticate
setup, but could someone rule that possibility out? The current
authenticate-then-encrypt mode would most likely prevent such attacks.
The encrypt-then-authenticate modes would provide any adversary with
the MACed data and the MAC in plain.

It seems like a tradeoff between concealment and integrity.

Personally, I do believe that any fix to a protocol with such
deployment should be targeted at the problem in question, unless there
are serious reasons to believe that the old mechanism is beyond
repair. I do think we are not in that case yet and a mechanism to make
the pad part of the MAC as I proposed in an earlier e-mail is
sufficient.
However, I also believe any solution is better than no solution at
all, and I do think that this WG should decide on a document to update
RFC5246, which either fixes the issue or replaces the CBC
ciphersuites.

regards,
Nikos

[0]. Contini, Scott, and Yiqun Yin. "Forgery and partial key-recovery
attacks on HMAC and NMAC using hash collisions." Advances in
Cryptology–ASIACRYPT 2006 (2006): 37-53.

[1]. Fouque, Pierre-Alain, Gaëtan Leurent, and Phong Nguyen. "Full
key-recovery attacks on HMAC/NMAC-MD4 and NMAC-MD5." Advances in
Cryptology-CRYPTO 2007 (2007): 13-30.

---

From: Russ Housley <[email-masked]>
Date: Mon, 11 Feb 2013 17:02:14 -0500

> (It looks as if NSS have until 2030 before they need to support TLS1.2 with HMAC-SHA256)

No.  That is the date that we want to complete the migration, so support needed to be added 5 to 10 years prior to that.

Russ