It is my understanding that:

  1. In TLS, the hash function is used only in HMAC construct.
  2. SHA-1 is secure when used in HMAC.
  3. TLS 1.2 switched the PRF used to derive the symmetric keys to no weaker than SHA-2, regardless of ciphersuite, thus in TLS 1.2 the hash function named in the ciphersuite is used only for HMAC during bulk data transfer.
  4. TLS_RSA_WITH_AES_128_CBC_SHA256 seems no more secure than TLS_RSA_WITH_AES_128_CBC_SHA, but has more bandwidth overhead (extra 12 bytes each record, which may be up to 16KB long).

Is the above correct? What was the rationale for defining the CBC SHA-2 ciphersuites in TLS 1.2? Was it a hedge against HMAC_SHA1 getting catastrophically broken but in such a way that leaves HMAC_SHA256 intact?

If my analysis is correct, does it mean that there is no point in supporting TLS_RSA_WITH_AES_128_CBC_SHA256? Is this the reasoning behind Android 5 and golang not supporting CBC_SHA256?

Note: I know about PFS and AEAD, this is a question about the merits of CBC_SHA256 vs. CBC_SHA.

  • 1
    It's the same reason why AES-256 exists. People assume that bigger is better.
    – user10211
    Mar 22, 2015 at 14:10
  • @TerryChia I disagree about AES-256. There are batch attacks that make knowledgeable people say AES-256 is not overkill, at least for some cases. I don't know whether a normal shopping site needs to worry. paper: cr.yp.to/snuffle/bruteforce-20050425.pdf (mentioned here: imperialviolet.org/2014/05/25/strengthmatching.html and here: ietf.org/mail-archive/web/cfrg/current/msg06370.html)
    – Z.T.
    Mar 22, 2015 at 19:27
  • Small point: 1.2 makes the PRF hash SHA256 for old suites, but new suites override that, and the (new) _SHA256 and _SHA384 suites do use the named hash for PRF even when it isn't needed for data HMAC (namely GCM and CCM). That said I concur HMAC-SHA1 is secure, but OTOH HMAC-SHA256 or 384 doesn't cost enough to worry about. Apr 2, 2015 at 17:47
  • @dave_thompson_085 I alluded to this in "no weaker than SHA-2". I think the answer to my question of the rationale behind the CBC_SHA256 ciphersuites is only in the mailing list archives.
    – Z.T.
    Apr 3, 2015 at 13:09

1 Answer 1


I've read the history of the work on this part of the TLS specification.

Eric Rescorla (co-editor of TLS 1.1, 1.2 and 1.3) posted on Dec 31st, 2007 on IETF TLS working group mailing list about a work item called "Issue 66: HMAC-256 based ciphersuites" for the next draft of TLS 1.2 (then called RFC4346-bis, i.e. a revision of TLS 1.1, now known as RFC 5246).

The originator of the idea is unknown.

The reason to add the new cipher suites is because it's weird for TLS 1.2 to switch the PRF to SHA-256 and then not allow SHA-256 for the bulk encryption authentication.

The idea was supported by Uri Blumenthal (MIT Lincoln Lab) saying SHA-1 has weaknesses and there is no need to wait for it to be broken before replacements are defined.

Nikos Mavrogiannopoulos (author of GnuTLS) supported the idea to match the cryptographic strength of the primitives (especially of AES-256).

Pasi Eronen (Nokia, lots of work on EAP) suggested the names of some of the new cipher suites.

Then there was some talk about the right size of hash function to match to each cipher between MIURA Fumiaki (Nippon Telegraph and Telephone), Florian Weimer (BFK, Red Hat, recently worked on fixing Shellshock), Ken Peirce who suggested to use NIST "bits of security" metric the solve the dilemma, Jeffrey A. Williams and Bodo Möller (recently worked on fixing Heartbleed) who provided links and explanation that "128-bit MAC security should be perfectly fine even for applications requiring 256-bit encryption security".

The TLS spec was updated (presumably by Eric Rescorla) with the new cipher suites and published in draft 8 which was out on Jan 25th, 2008.

The draft 8 change log reads, in part: "Added support for SHA256 cipher suites", no rationale.

In the final version of the specification, in the list of changes since TLS 1.1, says "Added HMAC-SHA256 cipher suites", again, no rationale. The cipher suite list in appendix C remained unchanged since draft 8.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .