Subject: Re: [TLS] Issue 66: HMAC-256 based ciphersuites

From: "Nikos Mavrogiannopoulos" <[email-masked]>
Date: Tue, 1 Jan 2008 13:17:25 +0200

One more argument for adding those ciphersuites, is that they allow
increasing the security level of a connection to more than 128 bits. Now the
weakest link in a TLS session seems to be the HMAC, if all the other
parameters are negotiated using a 256 bit equivalent security.

Although 256-bit security level might seem too much, I'd note that we
already have AES-256.

On Jan 1, 2008 12:49 AM, Eric Rescorla <[email-masked]> wrote:

> Someone, I can't remember who, suggested that we add
> HMAC-SHA256-based ciphersuites (i.e., ones that use it as a message
> MAC) directly in TLS 1.2. I'm waffling as to whether it's a good
> idea.
>
> Arguments for:
>
> - We made it the default for the PRF.
> - It's weird to to to all this trouble and not define them.
>
>
> Arguments against:
> - There's nothing known wrong with HMAC-SHA1
> - This revision is about flexibility, not actually adding new
>  digests.
>
> Comments?
>
> -Ekr
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: <[email-masked]>
Date: Tue, 8 Jan 2008 12:53:25 +0200

I agree with Uri that adding SHA256-based suites is reasonable (and
also agree with Ekr's argument, "It's weird to to to all this trouble
and not define them"). And having them in the main 1.2 spec would be
simpler than a separate spec.

To be concrete, I'd suggest adding the following:

TLS_RSA_WITH_AES_128_CBC_SHA256   
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256   
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA256

(or would 256-bit AES be enough?)

Best regards,
Pasi

> -----Original Message-----
> From: ext Blumenthal, Uri [mailto:[email-masked]] 
> Sent: 01 January, 2008 03:43
> To: [email-masked]
> Subject: Re: [TLS] Issue 66: HMAC-256 based ciphersuites
> 
> 
> I am for adding SHA256-based suites. We want to phase SHA1 out and
> phase its probable replacement in.
> 
> SHA1 did exhibit some weaknesses. and we hardly want to wait and see
> whether they will turn into exploits some day.
> 
> 
> On 12/31/07 5:49 PM, "Eric Rescorla" <[email-masked]> wrote:
> 
>

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 8 Jan 2008 11:03:10 -0500

SHA-1 is being deprecated, AES-128 is not. Therefore I recommend defining AES-128 as well. Might even want to consider AES-192.

Also, I didn't keep track of ECC-based suites addition - I hope they are defined and are using SHA-2.

On 1/8/08 5:53 AM, "[email-masked]" <[email-masked]> wrote:

Best regards,
Pasi

--
Regards,
Uri

---

From: [email-masked] (MIURA, Fumiaki)
Date: Wed, 09 Jan 2008 13:45:01 +0900

> TLS_RSA_WITH_AES_256_CBC_SHA256   

Why not SHA512 for AES256?

For example, FIPS 180-2 say that `security (bits)' for SHA-512 is 256
in page 3.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 09 Jan 2008 10:30:17 +0100

> For example, FIPS 180-2 say that `security (bits)' for SHA-512 is 256

Does this estimate also apply when using SHA-512 as a building block
for an HMAC?

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: [email-masked] (MIURA, Fumiaki)
Date: Thu, 10 Jan 2008 19:37:52 +0900

> Does this estimate also apply when using SHA-512 as a building block

I think yes, theoretically.

"Message authentication using hash functions: The HMAC construction"
  <URL: http://www-cse.ucsd.edu/users/mihir/papers/hmac-cb.pdf>  says:
| As shown in [12, 2], birthday attacks, that are
| the basis to finding collisions in cryptographic hash
| functions, can be applied to attack also keyed MAC
| schemes based on iterated functions (including also
| CBC-MAC, and other schemes). These attacks ap-
| ply to most (or all) of the proposed hash-based
| constructions of MACs.

But, I don't know any realistic attacks if we properly refresh the
key.

---

From: Ken Peirce <[email-masked]>
Date: Tue, 15 Jan 2008 08:00:07 -0800 (PST)

I think that we should provide cipher suites with uniform cryptographic strength. We should use the NIST "bits of security" metric to match the encryption key size and type as well as the hmac type. Use SHA 256 for AES128, etc.
   
  Ken Peirce

"MIURA, Fumiaki" <[email-masked]> wrote:
  At Wed, 09 Jan 2008 10:30:17 +0100, Florian Weimer wrote:
> 
> * Fumiaki MIURA:
> 
> > At Tue, 8 Jan 2008 12:53:25 +0200, 

says:

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 15 Jan 2008 16:44:08 -0800

Ken and all,

  I believe this is a very good suggestion and/or approach.

Kindest regards,

Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

Ken Peirce wrote:

> I think that we should provide cipher suites with uniform
> cryptographic strength. We should use the NIST "bits of security"
> metric to match the encryption key size and type as well as the hmac
> type. Use SHA 256 for AES128, etc. Ken Peirce
>      > > At Tue, 8 Jan 2008 12:53:25 +0200, wrote:
>    ----------------------------------------------------------------

---

From: "Bodo Moeller" <[email-masked]>
Date: Thu, 17 Jan 2008 11:41:58 +0100

> I think yes, theoretically.

Theoretically, this is true.  (By the way, note that there are now two
generations of research papers with HMAC security results:

http://www-cse.ucsd.edu/users/mihir/papers/hmac.html
http://www-cse.ucsd.edu/users/mihir/papers/hmac-new.html

The latter says that collision attacks against a hash function don't
mean it is bad for HMAC.  Still it's probably a very good idea to
phase out SHA-1.)

However, if we look specifically at TLS, we have a sequence number
space of size 2^64, which is quite far away from the 2^128 where we'd
expect to run into birthday collisions with SHA-256.  So the
theoretical attack doesn't apply, and we should be able to expect more
than 128 bits of security from HMAC-SHA-256 as used in TLS.  In fact,
even 128-bit MAC security should be perfectly fine even for
applications requiring 256-bit encryption security.  This is because
the reason for demanding such a huge security margin is long-term
security -- we are thinking of attackers who might spent half an
eternity trying to break our encryption.  The window for potential
attacks against MAC authentication in TLS, in contrast, is closed once
the connection is over.

Bodo