14
$\begingroup$

It seems the only specified CTR mode ciphers in TLS are all GCM based.

GCM ciphers run AES-CTR and do authenticated encryption with a MAC based on Galois-field arithmetic ("GHASH") - and the latter seems to be difficult to get right in software (side-channel attacks, constant time) or require CPU hardware support (e.g. Intel AES-NI / PCLMULQDQ) which in turn might be manipulated/weakened via microcode updates/implants.

On the other hand HMAC-SHA256 seems relatively simple to do right in software and when used together with AES-CTR and a encrypt-then-MAC scheme.

So why are there no modes like TLS_DHE_RSA_AES128_SHA256?

The closest I could find is this unfinished, expired IETF draft.

Improve this question
$\endgroup$
  • $\begingroup$ Perhaps because SHA256 is unacceptably slow - think 13 cycles/byte minimum (on top of the encryption cost). $\endgroup$ – orlp Oct 27 '13 at 9:16
  • 1
    $\begingroup$ Well, AES-CBC-(HMAC)-SHA256 has that too, doesn't it? And SHA1 is less secure. And then you could have a AES-CTR-(HMAC)-SHA1 also. And the alternative of AEAD like AES-GCM is very new and not yet widely available. $\endgroup$ – oberstet Oct 27 '13 at 10:55
  • $\begingroup$ I guess the reason may be both AES CTR and GMAC can be computed in parallel and as you state both can be hardware accelerated by many modern CPUs - not a drawback. In fact, the peak AES throughput with these instruction sets often can only be realised with at least 8 blocks computed at once to hide instruction latency. CTR-HMAC-SHA256 doesn't have the same performance characteristics (with either CTR or CBC it would be dominated by the HMAC processing time). So why add CTR-HMAC at all, it doesn't seem to add anything that GCM doesn't already do quicker. $\endgroup$ – Stubabe Oct 27 '13 at 17:43
  • 1
    $\begingroup$ For reasons other than mere performance, e.g. simpler to get right in software without side-channel attack vectors. Also the principle cipher seems to be around longer than GCM. I am just wondering: why hasn't that RFC been finished years ago? $\endgroup$ – oberstet Oct 28 '13 at 19:13
  • $\begingroup$ Well they had the opportunity to fix the MAC record format in TLS1.2 to remove the padding oracle completely (either by MACing the padding or moving to a EtA model), they didn't (which would be a far better solution in my view). Other than that I don't see your objection to CBC + HMAC as TLS1.1 onwards uses an explicit IV. $\endgroup$ – Stubabe Oct 28 '13 at 20:58
14
$\begingroup$

Short answer:

There would be nothing (that isn't already wrong with TLS) necessarily wrong with a CTR + HMAC cipher suite, but the technical merits are only one factor in a technical feature getting to RFC status in the TLS working group.

Without being discourteous to the TLS Working Group (WG) participants or process, other reasons can be: political (including national/standards body alignment); personal/corporate preference/motivation; historical timing; resistance to change (modifying implementations is an often-cited cost); fear/uncertainty/doubt/apathy/debating skills etc. TLS standardization happens very much in a real world implementation + real humans interacting environment, where the isolated technical merits of an idea are by no means the only measure of, or contributing factor to, success.

Why the draft-ietf-tls-ctr in particular never made it to RFC status (as part of TLS 1.2 or separately) is a little murkier, but my best guess is that a combination of:

  • timing and politics: probably most importantly, AEAD modes such as GCM, many based on CTR mode, and in the case of GCM favoured by a NIST standardisation process, came along early in the TLS 1.2 process and probably supplanted CTR in the thinking of the WG editors/participants.
  • uncertainty: CTR in 2006 was relatively less known and trusted compared to CBC.
  • doubt: there were some concerns stated in the TLS WG discussions about its use in DTLS and with explicit vs implicit IVs
  • Eric Rescorla was both an author for draft-ietf-tls-ctr and co-editor of the TLS 1.2 draft, so I suspect once GCM became a preference for the WG he stopped editing and pushing the CTR mode.

Longer timeline:

  • Nov 2005

    First mentions of draft-ietf-tls-ctr at Oct 2005 TLS WG meeting, at this stage not a chartered WG item.

  • Feb 2006

    draft-ietf-tls-ctr 00 begins life as a companion draft to the TLS 1.2 draft 00.

  • March 2006

    draft-ietf-tls-ctr is listed on the March 2006 TLS WG meeting agenda The TLS WG charter at that time explicitly discusses counter mode cipher suites as being a goal of TLS 1.2.

    The March 2006 TLS WG meeting minutes refer to draft-ietf-tls-ctr as being a chartered item and ready for review.

    At this point the First draft of TLS 1.2 specification, including CTR mode cipher suites milestone is marked as Done but CTR modes are clearly not in draft 1.2 specification at that time (or any other).

  • July 2006

    At the July 2006 TLS WG meeting draft-ietf-tls-ctr is described as ready for last call in the minutes.

    No last call for draft-ietf-tls-ctr eventuates on the TLS WG mailing list.

  • October 2006

    TLS 1.2 draft 02 is published, and AEAD/GCM modes are included for the first time.

  • November 2006

    At the Nov 2006 TLS WG meeting draft-ietf-tls-ctr is still on the agenda, and the minutes show discussion centered around the counter and IV structure. A GCM mode draft is mentioned as being imminent.

  • December 2006

    Some concerns about counter mode, in particular counter/IV structures, are discussed on TLS WG mailing list.

  • January 2007

    Discussion of CTR mode on the TLS WG mailing list has dried up apart from some discussion about potential issues with DTLS, and GCM mode is being actively discussed.

  • March 2007

    draft-ietf-tls-ctr is still mentioned in the TLS 1.2 charter, but no longer on the March 2007 TLS WG meeting agenda, and all discussion in the minutes is about GCM.

    From this point on draft-ietf-tls-ctr is not mentioned again, and no CTR modes end up in TLS 1.2. GCM modes go on to be published in RFC 5288 about the same time as TLS 1.2 is finalised in RFC 5246.

Improve this answer
$\endgroup$
  • $\begingroup$ Thanks for collecting historical traces! The list of non-technical reasons (for non-existance of more TLS CTR) you give is compelling. Too bad;( $\endgroup$ – oberstet Apr 29 '14 at 9:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.