Re: [saag] A case against algorithm agility (long)

[Nico Williams <[e-mail]>]

On Sat, May 3, 2014 at 10:45 AM, ianG <[e-mail]> wrote:
> 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.

That's not what we generally mean by algorithm agility.
> 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.

That clarifies: you're against a-la carte negotiation.  (Actually, no,
you appear to be against algorithm agility in general.  See below.)

FYI, SSHv2 has a la carte negotiation of key exchange, host
authentication, and cipher+cipher mode (the last always as atomic
pairs) that since the beginning.  There's a case study for you.
Please demonstrate how it's been a problem.

> 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

"past"?

> stream ciphers to be blocks underneath, (d) the whole stream v. block
> debate, (e) the shift to AE, (f) changing keylength goals over time.

I agree that 3DES is NOT an appropriate substitute for AES, primarily
because 3DES has a very small block size (64 bits), which impacts on
re-keying considerations and authenticated encryption options.

I also agree that cipher and cipher mode MUST be negotiated as
registered pairs, not a la carte.  This is pretty clear, and I don't
know anyone who is arguing otherwise.

> 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.

It sounds to me like the only thing you have an argument against is
negotiation of cipher separately from cipher mode.  But no one is
arguing for the other side of that.  It seems to me like you're just
putting up a strawman -- yes, it's easy to knock down!

> [...]

> 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.

Bunk.  Software negotiates on behalf of people.

> 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.

We know how to protect against downgrade attacks.  The biggest problem
w.r.t. downgrade attacks is fallback reconnection, a particularly
obnoxious problem for TLS for historical reasons.

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

This is not really an acceptable argument.  Everything we implement
opens up the possibility of bugs.  It's very difficult to win such an
argument (DJB does this very well when it comes to EC, for example, so
it can be done, but that's a very particular case and not at all
germane to this discussion).

> 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?).

Nonsense.  The CBC IV chaining bugs were exploited against SSHv2.  We
were very glad back then to have deployed AES in counter mode as that
saved our butts.

> 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.

I don't buy this.

> 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.

Algorithms most definitely have failed us, sometimes spectacularly!
E.g., MD5, CBC w/ IV chaining, RC4, ...

> [...]

> 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?

It's very difficult to switch algorithms in PKIX.  I.e., we didn't
have algorithm agility for signature hashes.  You've refuted your own
argument.

>
> 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.

Configuration management is faster than patch application.  Way, way
faster.  In an emergency this is very handy.

> 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%

Performance matters.  Bad perf -> risk of substantial non-deployment.

> better than the other guy.  We pontificate on how CTR is better than
> GCM, because because, we enjoy poking our thumb at the NSA.

Huh?  GCM is a counter mode.  Just what the heck are you talking about??

> 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?

What has this got to do with alg. agility?

Nico
--