Subject: Re: [saag] draft-iab-crypto-alg-agility-01.txt

From: Peter Gutmann <[email-masked]>
Date: Tue, 14 Apr 2015 13:16:14 +0000

Viktor Dukhovni <[email-masked]> writes:

>Much of this discussion misses the point about multiple algorithms in TLS.
>In practice their purpose is not insurance against compromise of an
>algorithm.
>
>Rather, as I see it, the main reason for the multitude of algorithms in TLS
>is that TLS is a general-purpose building block for secure data transport
>that is used in many diverse environments.

I doubt it's even that, I'd say most of the algorithms were added "because we
can".  Looking at some of the stuff in there, IDEA, RC2, DH-DSS/DH-RSA,
Kerberos, Camellia, SEED, on and on, I mean does anyone really need, or even
want, the likes of TLS_DH_DSS_WITH_AES_256_GCM_SHA384,
TLS_RSA_PSK_WITH_NULL_SHA384, TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256,
TLS_ECDH_anon_WITH_NULL_SHA (these are all within the last few years or so, so
no excuse about being present for historical purposes)?  Is there any
extension-to-TLS RFC that limits itself to only two or three new suites (the
SCSV draft doesn't count)?  Everyone just shovels in every combination they
can think of, because whoever dies with the most cipher suites wins.

>A single cipher-suite in TLS would not serve those different needs.

Two or three would cover most situations.  We certainly don't need the three
hundred and twenty-nine (!!) suites we currently have defined.  Looking at
Firefox (which I happen to have open at the moment), it negotiates exactly
eleven suites, and of those half are ECDHE-something ones.  Not three hundred,
just eleven.

(How many TLS implementations are there in existence?  20?  30?  There could
well be an order of magnitude more cipher suites than there are TLS
implementations).

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Apr 2015 14:43:16 +0100

<no hats and all that>

While I don't agree with all of what Peter said, I do
like this bit...

> eleven suites, and of those half are ECDHE-something ones.  Not three hundred,

300+ TLS ciphersuites is plain dumb though I think I've said
that before:-) I hope Russ' draft ends up saying something
equivalent.

My gut says that Eleven is still too many, even if it's way
better than today.

I once suggested we'd be fine with a 2 bit ciphersuite field
in TLS: 00 meaning current, 01 meaning backup, 10 meaning
proprietary (*) and 11 being reserved, just in case. While I would
like that, it's probably not possible, given the issues with
AES h/w vs. chacha (performance) and with AES GCM vs CCM (work
with deployed h/w). I see no reason why TLS1.3 (say) couldn't
just pick one best option and a backup for all of ecdh, hash,
prf etc (call 'em thing#1 and thing#2). So that'd mean we'd
end up with only 2 x 3 = 6 real ciphersuites and then a code
point for "proprietary" (for the GOSTs etc of the world which
won't go away), so 7 in total. I'd argue we could just
deprecate all the rest if we got agreement on that. And we
could also agree (in Russ' document) that we only add new
ones when we also kick out some old ones. And all that
can be done easily enough with e.g. a separate IANA registry
for the current preferred cipherssuites which has as a rule
that it must always be of size 7 or something.

So maybe an interesting question to ask for TLS and other
protocols is: "how small is the minimum set of ciphersuites
(or equivalent) that meet current real use cases." I'd say
Russ' document could have a useful section on such an
analysis maybe using some of the above. And I think that
that might also apply to other protocols as well as TLS
almost without changes.

Cheers,
S.

(*) There are real national alg requirements for some
protocols. But if you receive a packet that uses one of
those, in almost all cases you (even Rich:-) only support
a handful of such national algs, so you could just try
them all until one works or all have failed. That would
mean national or vanity ciphers no longer even need to
get code points, removing a piece of tricky politics
from the IETF entirely - whee hee:-)

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 14 Apr 2015 17:23:36 +0300

> that before:-) I hope Russ' draft ends up saying something

I think that this number most indicates two issues. (1) TLS requires a
different ciphersuite based on the server's certificate type, so we have
4 ciphersuites for AES-128-CBC-SHA1 to handle DSA, RSA, ECDSA, static DH
certificates. (2) For some reason TLS was dragging the never deployed
static DH key exchange further increasing the number of potential (but
not really used) ciphersuites.

> just pick one best option and a backup for all of ecdh, hash,

What would that buy? Would the protocol be simpler? Yes. Well it be
applicable to more than the use cases the initial author thought? No.

We had AES-GCM defined in TLS few years ago. It is a very modern AEAD
ciphersuite, heavily optimized in high end CPUs and according to the TLS
WG it would have been the only ciphersuite needed. For small systems
AES-GCM was ignored and new ciphersuites were defined based on AES-CCM.
Chacha was also also defined to reduce CPU and memory usage on high end
servers. So what would have been the advantage if TLS had decided to
mandate AES-GCM only? It would have been more CPU and memory spent in
servers, and more expensive hardware for embedded systems, or we would
have a bunch of TLS-like protocols for each use case defined by the
entities that now propose new ciphersuites.

So, there are clear advantages of having an agile TLS protocol.

regards,
Nikos

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Apr 2015 15:41:17 +0100

> entities that now propose new ciphersuites.

I think you're misreading my mail. I described a way of supporting
chacha, aes-gcm and aes-ccm, which I do think are all needed going
forward. That's three things. If we have one other orthogonal pair
of things (probably one based on p256 and one based on 25519) then
that's six suites. And I'd add one code point for "proprietary"
making 7. So my message was totally consistent with maintaining
support for everything you mention above.

I just want to kill everything else:-)

S.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 14 Apr 2015 14:42:30 +0000

>I just want to kill everything else:-)

You shoot, I'll reload.

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 14 Apr 2015 14:45:32 +0000

> >I just want to kill everything else:-)

When you consider that many of these are national standards... you're gonna need a bigger gun. :)

Less flippantly, at the Seattle interim I suggested partitioning the space, like the good old days of network Class A, etc.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Apr 2015 16:33:45 +0100

> gonna need a bigger gun. :)

Not if we can in future squeeze 'em all into one codepoint :-)

> Less flippantly, at the Seattle interim I suggested partitioning the
> space, like the good old days of network Class A, etc.

So also more seriously, you're employer (as a big CDN) is maybe
one of the hardest cases, so in a TLS1.3 environment, aside from
the set of ciphersuites we all want to support, (e.g. my 6 from
before or wherever that ends up), how many different suites
for national algs (not legacy stuff, just national algs or
vanity suites) do you think you might have to support globally?

And how many of those are potentially in-play for any given
session/connection/client or whatever's appropriate if you'd
have to peek and poke about to figure which alg was used for
my putative "proprietary" ciphersuite codepoint?

My guesses would be that there're about 5 more ciphersuites
about which even a big CDN would need to care and that for
any connection only one is likely to be worth checking for.

And once you have a TLS session or similar, then you have
state that tells you which ciphers are in use, so this only
impacts in a hopefully minor way on TLS handshakes and
equivalent.

(If you can't answer in detail, I understand, but in that
case if you can say my guess is mad/not-bad that'd be useful
too.)

Cheers,
S.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 14 Apr 2015 08:49:30 -0700

> my putative "proprietary" ciphersuite codepoint?

What problem does this proposal (blind guessing) solve? Why is it a
problem that we have ciphersuites that most people don't use, if there
are people who use them? Implementations can avoid the cost of
implementing all but the most popular suites if they want.

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

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Apr 2015 17:06:58 +0100

> implementing all but the most popular suites if they want.

I think it'd be easier for implementers and would result
in fewer uses of ciphersuites on which we don't have
rough consensus as to goodness. Both are good things I
think.

There is also a lot of (IMO) wasted effort when someone
is tasked to get their national alg "into" IETF specs.
Someone probably has to translate into English/I-D and
get all the required permissions, and that can take years,
literally. (And when done, then start over on the next
generation of national alg.)

Then they need to negotiate all the fun of the baroque IETF
and IANA processes we have setup for TLS, IPsec, S/MIME,
PGP, SSH, ... in order to get all the relevant code points.
(Most countries seem to prefer to want the full set for
some reason.)

And from the IETF side, doing all that N times makes it
very hard for us to sanity check algs, as we can't easily
say no to one country having said yes to some (as we have
already done) and we're also not in a good position to
get cryptographic review on such things as most people
don't care (vendors will put these in if paid enough).
And the countries concerned can pay folks to contribute
to OSS if they want. CFRG also don't want (AFAIK) to be
in the biz of telling the IETF that country-X's alg is
crap or good.

And lastly, some area directors would be saved from having
to be all nice and uber-polite dealing with country-level
politics, not that that's at all a consideration for me:-)

So there's the potential I think to save a bunch of IETF
participants a bunch of otherwise wasted effort and to
simplify the code we care about.

S.

PS: The above is somewhat wishful thinking - the fact that
TLS1.3+ will have to keep dealing with legacy (i.e. <=TLS1.2)
ciphersuites probably forever, means that it's not so likely
we get to fix this. Which is a pity.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 14 Apr 2015 16:55:04 +0000

> My guesses would be that there're about 5 more ciphersuites about which
> even a big CDN would need to care and that for any connection only one is
> likely to be worth checking for.

If you doubled that I'd feel comfortable with that as a good guess.