[saag] A case against algorithm agility (long)

[ianG <[e-mail]>]

I've jotted down some notes on the case against agility, as mooted.
Sorry, long.

It should be called "algorithm agility considered harmful" but I've
found that some people are irrationally offended by words.  Offense
doesn't worry me, but distraction helps nobody.

By algorithm agility, I mean the ability to swap AES for TDES for
ChaCha20 or MD5 for SHA1 for SHA256 or GCM for CBC for CTR or RSA for EC
for DSA for ... and including small groupings of same such as
AES+HMAC+SHA+CBC.  The ability to select the entire suite is another
issue, maybe discussed later.



1.  Black boxes they ain't.  Algorithms are sometimes characterised as
black boxes that can be substituted at will.  Unfortunately it's only a
hope, it's not met in practice.

Consider (a) the emerging sense of sponge constructions, (b) emerging
calls for 32 byte block sizes and a past of 8 bytes, (c) tendency for
stream ciphers to be blocks underneath, (d) the whole stream v. block
debate, (e) the shift to AE, (f) changing keylength goals over time.

It's simply not the case that you can reliably blackbox the cipher, the
hash, the mac, the mode or any other component.  Yes, you can design
something that substitutes in various black boxes according to this
vision, and you can force all your algorithms to work as black boxes but
the result is inelegant, klunky and undesirable.  Hard to maintain, and
new models cause contortions leading to weakness.


2.  Strength.  Universal substitution is bad, strength alignment is
needed at a minimum, and this is not a casual endeavour for mindless
tweaking.

Draft section 2.4 makes it pretty clear that just switching black boxes
back and forth is not sufficient, as the algorithms should be matched in
strength.  So, if we've decided to allow algorithm agility, we have in
effect outsourced strength alignment to the public, which is someone who
isn't capable of doing it.  e.g., we are negligent by charter, we've
squandered our chance to actually do what we ourselves are capable of
doing:  designing a matched suite.


3.  Config.  The choice of agility is a claim that the user population
can make good choices.  Yet, this isn't met by experience:  Nobody
(approximately) has confidence in user-land config strings, e.g.,
OpenSSL.  They are so complicated and there are so many traps that only
a real expert has confidence in own work, and that's not actually seen
often enough to justify talking about it.  Everyone (approximately)
relies on defaults delivered, and so does everyone upstream, until you
discover that your experts are also relying on other defaults from other
experts who were relying...  c.f. Android debacle.

Over at the BetterCrypto group that publishes a guide on how to
configure and use safer stronger algorithms, they seem (by my
observation) to spend about half their time on one thing:  OpenSSL
config strings.

What a waste.  For what?


4.  Marginality.  Any benefits from tweaking/swapping/improving blackbox
algorithms are marginal and/or esoteric.  For the most part, any cipher
gets you 99.999% of the grade.  Same with any HMAC, any mode properly
implemented.  The only people who can or will crack weaker algorithms
(DES?  RC4) are people who will also bypass the crypto, and are already
doing it.

So if we were doing risk analysis (which is the only scientifically
founded method, albeit weak) anything above DES is a waste.  Now, it so
happens that for next to no cost, we can do much better than DES, e.g.,
AES or better even.  *So we might as well* and thus I fall also to
hubristic desire for more algorithmic delight.

But the /difference/ between is not going to effect the user public.  It
certainly doesn't justify enabling a difference.


5.  Negotiation between software agents is a crock.  Software agents
don't negotiate, people do, and that's by definition.  The complicated
matching of ordered preferences that is called agent negotiation is a
minefield of errors, bad user experience, and opportunity to attack.
The complication ensures that implementations will not have an easy ride
together, and even one implementation negotiating against itself is no
easy thing.


6.  Attacks.  The existence of algorithm agility opens up the
possibility of the downgrade attack.  E.g., trick the config string
(below) to default to the NULL cipher.  Or trick the negotiation to
choose the weakest cipher.  Etc.

It also opens up the possibility for bugs (benign) and lousy user
experience.

7.  Need.  We still have no evidence that any attacker ever has attacked
the crypto algorithms in TLS or other properly designed protocols (iii).
 The closest we've got (to my knowledge) is the 512RSA phishing attacks
in the far east (yes, take that choice away, why on earth do we let
users choose key sizes?).

We simply have no reason to believe that any of the well-designed
algorithms will be cracked in the next 10 years.  Our expectation that
they could, derived from WWII warstories and thrilling self-serving
media headlines, is not a foundation to say there is any expectation at
all.  It seems that we expect them to fail, and we act as if they will
fail, *because we can*.  Not because it is likely.

Meanwhile, our actual record of security is rock-bottom because while we
put exorbitant attention on the next-to-impossible case of algorithm
failure, we ignore the actual, measurable and costly failure that bad
protocols contribute to in userland:  phishing, server breaches etc.
"Out of scope" means we aren't professionally doing risk analysis.


8.  Speed.  In contrast, ciphers are so slick these days that the best
today competes with the best of 20 years ago, CPU cycle-wise.  And
99.99% of the users have so much CPU that they can never notice the
difference.

(This is not to be confused with those who work at the sharp end, with
heavily loaded and balanced machines.  These are the people who can pay
for performance, and do.  They can also pay their suppliers and
suppliers' suppliers to influence standards orgs, so it's probably wise
to remember that these people can deal with any sub-optimal performance
by two ways:  buy influence here, or buy bigger boxes at the shop.)

(Same applies to all HMACs, modes, etc.)


9.  Problems.  In contrast, there are plenty of problems in the
protocol, the layouts, the interactions, the features.  Check the
evidence:  as far as I am aware, all failures were outside the algorithms.


10.  Track record.  Historically, no record of agility saving us.  The
one time it might have saved us was in switching to RC4.  That might be
called a save, but it wasn't really;  it was really a switch in protocol
to use stream ciphers, and we switched back to arguably the worst cipher
available.  There was no designed agility to switch from block to stream...

So if we think RC4 saved us, then we can (e.g.) no longer argue for
stronger ciphers...


11.  MD5.  And then there is MD5 in TLS;  why did it take so long to get
rid of it?  It turns out that algorithm agility wasn't universally
deployed all the way through.  Why not?  Because it wasn't easy to put
algorithm agility into all the places.

So the one time we really needed it ... it wasn't there for us?


12.  Distros rule!  Actually getting a live switch *in algorithms* out
to userland is very difficult.  It's harder to get people to change
their config strings than it is to send out a new distribution.  Every
Linux sysadm understands apt-get.  Every apple user understands Security
Update, click to restart.  Every MS admin understands backup & re-install.

Relatively few of them understand how to tweak the settings.  Indeed,
few of them have the first clue about algorithms.  Indeed, it's really
bad advice to say "switch to RC4" because we have little idea as to
whether they'll get it right, or whether it'll trigger some other problems.


13.  Arrogance.  There's something of a hubristic bias in algorithm
agility.  We do it because we can, because its cool, and we're happy to
ignore the downstream noise.  We invent rationales as to why we should
do it.  We talk about how we optimised our implementation to get 5%
better than the other guy.  We pontificate on how CTR is better than
GCM, because because, we enjoy poking our thumb at the NSA.

I once knew a guy who said "it is my right to use odd-length RSA keys."
 I lost a couple of days debugging before I figured out why his keys
would not communicate with mine.  It is fine to do this in isolation,
pushing rights and beliefs, but really, are we in the business of
religion, exporting democracy, motherhood and apple pie?

Or are we in the software business?  Trying to get the maximum
protection across to an Internet of users?






What this doesn't argue against:

A.  the past.  E.g., TLS is what it is, here and now, this is not an
argument to suggest that TLS WG should drop everything and stop doing
algorithm agility.  They're stuck with their legacy, and the good thing
is that we now have a good solid historical example to prove or disprove
the hypothesis.

B.  this ID shouldn't be written.  Regardless of the hypothesis, there
are many protocols that use the technique.  Documentation of it is a
good thing.  However, it is better to encourage them to use better
practices than to laud the best practices of the past, once past their
sell date.



Notes.

(i) where above I mostly write about ciphers, the arguments extend to
other components and choices such as HMACs, modes, public key, lengths etc.

(ii) this is just today's effort.  I'll keep refining it, fire away!

(iii) by properly designed protocols, I generally exclude wireless which
are designed to be weak and breachable.  By attack, I mean an aggressive
breach including measurable damages.  I accept rework as measurable
damages, typically, but academic demos and reputation thefts don't cut it.