[Cryptography] a question on consensus over algorithmic agility

[ianG]

On 26/06/2014 22:21 pm, John Kelsey wrote:
> There are a couple point I think are really important to think about if you're trying to get algorithm agility in a protocol:
> 
> a.  The security benefit of algorithm agility is entirely in being able to *stop* using some algorithms while still functioning.  

Very good point.  There isn't anything about that.

> This means that you only really get this benefit if you have at least two ciphersuites that are both SHALLs.  If everyone implements RC4 + CRC32 (the SHALL), and some people also implement AEC-GCM (the SHOULD), then when someone finally realizes that RC4+CRC32 is insecure, you can't actually get rid of it.  Indeed, version rollback attacks will work even on implementations that support AES-GCM, because they have to be able to interoperate with implementations that don't.  


Good point.  So requiring algorithm agility is actually inadequate.
Another timely reminder that these people require without understanding.

> b.  A lot of the time, the "algorithm" that gets broken isn't a cryptographic primitive like AES, but rather some surrounding chaining mode or padding scheme or something.  


I would go further.  It's not happened in modern times with properly
designed systems.  (By "properly designed" I exclude things like
wireless which seemed crippled by design.)

If you think I'm wrong, by all means, shout!

What we have seen is a steady run of failures in the outer areas.  So it
seems unfair to blame the humble algorithm for protocol failings.

> This means that if there are two ciphersuites, they should be pretty different to minimize the overlap between them.  For example, you might do AES-GCM and 3DES-CBC+HMAC-SHA256.  The same idea applies to more ciphersuites.  


Yes, but to take this to its conclusion, there should be two
mini-protocols inside the protocol.

> c.  It's critical to make sure there's a simple way for a particular implementation to stop using a given algorithm, and that this is built into the protocol.  The ciphersuite negotiation probably needs to be really simple.  

Right.  Any ideas?  I've none.  Or, at least, all ideas I have seen that
actually work reduce to "re-install".


> Comments?


All good points, I have a rant somewhere with 14 points against.
However, you haven't opined on the original poser:

1.  Should IETF insist on MUST for algorithm agility?  That is, all
protocols should have it, in general ?

2.  Should IETF insist on MUST for algorithm agility in the special case
of the opportunistic extension to TCP, called TCPCrypt ?



Perhaps I should explain some more context.  IETF WG for TCPCrypt has
been formed to create an opportunistic extension to TCP.  Now it has to
write its charter.  Then they will start on the protocol.

In the charter they set down rules.  Right now the rules state that
TCPCrypt MUST have algorithm agility.  I for one think that is daft [0],
but I am told it is IETF consensus.

So what I'm actually trying to show today is ... it may well be IETF
consensus to insist on algorithm agility, but it ain't the consensus
outside the IETF.  Outside, we all look on and shake our heads.  In
wonder.  Can't they see the cross they create for themselves to carry?

And, it might be that the IETF are a somewhat self-reinforcing crowd ...
and we're about to see a reinforcing cycle where they scare away anyone
who thinks agility results in white elephants.

So, what do we think, here, those of us who aren't steeped in IETF?

Algorithm agility?  Thumbs up?  Down?



iang



[0] for a longest time:
http://iang.org/ssl/h1_the_one_true_cipher_suite.html