Subject: [TLS] Combinatoric explosion and cipher suite policies

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 May 2008 07:31:32 -0700

[Speaking as an individual]

I'm geting increasing concerned about the combinatoric explosion
of cipher suites. Currently, TLS has at least
12 key exchange methods:

   RSA, DHE_RSA, DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA, DHE_DSS,
   DH_DSS, ECDH_ECDSA, ECDHE_ECDSA, DHE_PSK, ECDHE_PSK, PSK

It supports at least 5 ciphers:
   
   3DES, AES-128, AES-256, SEED, Camellia, RC4

With 2-3 MACs:
   
   HMAC-SHA1, HMAC-SHA256, HMAC-SHA384

And 2 block cipher modes:

   CBC, GCM

The above or mostly orthogonal (with GCM and RC4 being non-orthogonal
a special cases). As we all know, TLS does not have mix-and-match
ciphers but rather suites, so every combination requires its own
code point.

Now, let's consider what happens if we want to add a new MAC, e.g.,
Whirlpool. In principle, this could apply to the explosion of
KeyExchange * Cipher, to induce 48 new cipher suites. If we want to
add a new block cipher mode, e.g., OFB, this can be multipled by the
number of MACs as well to imply a stunning 144 new cipher suites.

Currently, we have plenty of code point space, though 16 bits isn't
infinite, however it's not clear to me that it's actually useful to
define every possible point in the space. It's well known that the
vast majority of TLS connections use a very small number of cipher
suites, and at least IMO, it doesn't really promote either interop or
security to have a huge number of options which can be individually
selected. It's also problematic, as Pasi notes, to have the code point
assignments for a single new algorithm spread over a bunch of
documents as people fill out the space.

Accordingly, what I'd like to see is the working group reach consensus
on (or perhaps affirm what I suspect is already the consensus) on
a core suite of algorithms/modes that we think are important to
support and that when adding a new algorithm we define only those
unless there's actual evidence that some other combination is
required. 

I propose that this set be:

Key Exchange: RSA, DHE_RSA, RSA_PSK, DHE_PSK
Encryption:   AES-128
MAC:          HMAC-SHA-256 *
Modes:	      CBC

* I'm most uncertain about this one, since it's really way too long
on the wire, but I guess the MAC truncation extension takes care of
this.

Alternately, if people feel it's valuable to support every possible
combination, we should discuss methods of minimizing the document
load associated with the new code point assignments. I've got some
thoughts on this, but as noted above, I'd rather avoid it.

-Ekr

 

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Len Sassaman <[email-masked]>
Date: Mon, 26 May 2008 10:23:17 -0700 (PDT)

On Mon, 26 May 2008, Eric Rescorla wrote:

> of cipher suites.

Likewise. I like the idea of having multiple ciphersuites in reserve, but
would prefer that there only be one ciphersuite active at a given time.

> Key Exchange: RSA, DHE_RSA, RSA_PSK, DHE_PSK

(Okay, I can see the utility behind the multiple key exchange algorithms,
but what's your rationale for these four?)

Best,

Len

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 May 2008 10:36:38 -0700

At Mon, 26 May 2008 10:23:17 -0700 (PDT),
> but what's your rationale for these four?)

In retrospect, I think I only want to say RSA and DHE_RSA.

RSA because this is basically the standard technique. DHE_RSA
because it's the only standards track key exchange compatible
with the current cert infrastructure that offes PFS.

I don't have a good argument for the other two (I thought I
did, but now that I think about it...) so I vote for losing
them.

-Ekr

---

From: Len Sassaman <[email-masked]>
Date: Mon, 26 May 2008 14:26:18 -0700 (PDT)

On Mon, 26 May 2008, Eric Rescorla wrote:

> with the current cert infrastructure that offers PFS.

I can get behind that.

On this topic (cutting down the cipher choices to the smallest number of
sane cipher-suites possible), I've intentionally avoided making too many
suggestions as to which ciphers should be chosen [0], since we're never
going to all agree on that, and I think it's crucially important that we
eliminate extraneous ciphers, and not important that any one person's pet
favorite be in the list [1].

I would like to see "backup ciphers" specified, though. I.e., an alternate
for each of the variables in the standard cipher-suite, such that we can
quickly switch away from a given algorithm if it is shown to be broken.
This has the same combinatorics problem that you brought up before, but it's
far more limited.

(I.e., if we go with your suggestion of
{RSA|DHE_RSA}/AES-128/HMAC-SHA-256/CBC, we'd need a total of five
cipher-suites -- the main two, and every combination with an alternate [2].
I don't think we need to have multiple alternates, since the chances of a
break that takes out two ciphers at once without enough time to handle
specifying the new alternates strikes me as unlikely, but even if we
wanted to handle that, it doesn't get too large.)

But I do stress that in suggesting this, I'm proposing that the only
"permitted for production use" cipher-suite(s) be the *main* one (or two).
[I'd be happy dropping RSA and just going with RSA_DHE, honestly, but I
can understand the reasons for keeping RSA]. The backup ciphers would
simply exist in the code, off-by-default, but available-for-testing, so
that should emergency strike, we're not rushing to foist barely-tested
crypto code on the public [3].

> did, but now that I think about it...) so I vote for losing

Thanks for clarifying that. I was trying to think of what your argument
might be, and came up with a few, but then realized my arguments for the
ECC-suites were more compelling than the ones I could think of for the PSK
ones, and those still didn't seem good enough to me to warrant adding
them [4].

Best,

Len

[0] Ian Grigg and I have been harping on this issue for the last few years
with regard to OpenPGP. More ciphers means more opportunities to break the
protocol -- a bigger issue than the mess of managing all these
cipher-suites, in my opinion.

[1] Otherwise, I'd be arguing for Whirlpool for use in any cipher-suite
that uses AES...

[2] One thing that has always bothered me about browser implementations of
TLS is the insistence that unsigned-but-encrypted traffic is useless. This
is somewhat off-topic to this thread, since it's mostly a GUI-design/HCI
issue, but I'd really like to see browsers operate with three modes:

1) unencrypted,
2) encrypted but unauthenticated (and without popup warnings!), and
3) encrypted+authenticated.

From the user point of view, the second need not trigger lock-icons and
other indicators of security -- but it would, I believe, help increase the
amount of encrypted traffic in use. Sure, man-in-the-middle attacks are
possible if we're using anonymous DH, or RSA_DHE with self-signed certs,
but given the number of times I've seen users switch to unencrypted web
browsing because of being scared off by popup-warnings, I think it's a
real shame that HTTP insists on the adage "you can't have encryption
without authentication." In my perfect world, nearly all HTTP traffic
would fall under categories 2 and 3.

(Which brings me to my other bite-my-tongue point: I'd really like ADH as
a special-case key exchange protocol -- but thinking about it, I realize
it's not necessary, since we could just use RSA_DHE with self-signed
certs, and make the browsers smart enough to treat them as an indication
to silently opportunistically encrypt, per behavior #2 above, unless the
self-signed cert was explicitly listed as trusted. So given that, I'll go
back to advocating we cut down on the excess options...)

[3] They'd be enabled in debug builds, and passing standards compliance
would require that interop testing be done on the backup cipher suites, but
that they MUST NOT be enabled for production use. When a break happens,
rev the TLS version and change the default cipher-suite.

[4] I do think we're headed toward ECC in the not-too-distant-future, but
it happens to be the present.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 May 2008 14:36:19 -0700

At Mon, 26 May 2008 14:26:18 -0700 (PDT),
> favorite be in the list [1].

Just so we're clear, I'm not suggesting that we remove ciphers.
That seems like a different and more complicated argument.

Rather, I'm suggesting that when someone asks to add algorithm
X, we only compose it with the other "main" algorithms.
For instance, if we were to add Whirlpool, I would want
to define:

RSA_AES_128_CBC_WHIRLPOOL
RSA_DHE_AES_128_CBC_WHIRLPOOL

Rather than all the other variants.

-Ekr

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 26 May 2008 17:48:43 -0400

I share your concern. But what about ECC-based suites? (Suite B)

On 5/26/08 17:36 PM, "Eric Rescorla" <[email-masked]> wrote:

-Ekr

--
Regards,
Uri       [email-masked]

---

From: Len Sassaman <[email-masked]>
Date: Mon, 26 May 2008 14:55:54 -0700 (PDT)

> That seems like a different and more complicated argument.

Ah, I see. I suppose I'll have to continue arguing my suggestion from time
to time, then. ;)

> For instance, if we were to add Whirlpool, I would want

[snip]

Well, I do support this, as it certainly helps the situation from getting
far worse. But I really wish we'd stop adding new algorithms, and start
retiring the ones that make less sense than others of the same class.

In the mean time, though, what you're saying is definitely worth adhering
to. I also agree with Uri's point that they should all be specified in the
same document.

Best,

Len

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 27 May 2008 17:40:45 +0200

> I share your concern. But what about ECC-based suites? (Suite B)

Can you purchase a TLS server certificate for ECC?

If the answer is no, then I believe ECC is not mature enough to consider
in this discussion.

/Simon

---

From: Martin Rex <[email-masked]>
Date: Tue, 27 May 2008 18:48:43 +0200 (MEST)

> If the answer is no, then I believe ECC is not mature enough to consider

This might be a hen-and-egg problem.

As long as the majority of SSL/TLS implementations out there doesn't
support ECC certs and crypto, there is no point in customers asking
for or using ECC certs, and therefore no business case for CAs
to offer them.  :)

The question is more whether either "we" (i.e. TLS-WG/IETF) believe in
Suite B algorithms and that we should make world adopt them for TLS,
or whether we think some particular government will assert sufficient
force (mostly by regulation) to make it happen (which might be
sort of difficult without a standard for COTS Software).

Personally, I think that moving to Suite B algorithms is probably a good
idea for pure digital signatures.  For online authentication like with
TLS, it don't see a pressing need to change, because the existing/deployed
algorithms are so much stronger than the rest of the software stack that
attacks at that level are extremely expensive and don't make any sense
in the commercial world.

And techically, moving the digital signatures to ECC and leaving TLS
and certs for online authentication at RSA makes a lot of sense, because
it _requires_ different certs for both purposes, and that is GOOD.
Digital signatures and online authentication (in particular repeated
and automatic/Single Sign-On style) are conceptually so very
different that one should never use the same keys for them.

Secretive Agencies and military customers with exagerated paranoia
likely have a different opinion on this topic and would probably
prefer to get Suite B algorithms in COTS Software as soon as
possible. 

-Martin

---

From: Mike <[email-masked]>
Date: Wed, 28 May 2008 20:04:02 -0700

> RSA_DHE_AES_128_CBC_WHIRLPOOL

Well now that we have the supported signature algorithms
extension, DHE_RSA and DHE_DSS are unnecessarily restrictive,
so you -could- merge them into just DHE and allow whatever
signature algorithm to be used.  This would help reduce the
combinatoric explosion.

On a separate note, I think that DH_anon should also be
maintained since it is useful for a quick renegotiation
(of an already secure connection) that also restarts forward
secrecy, without the overhead of sending certificates and
performing signatures.

Mike