[Ach] considering your experience in selecting the perfect config string, would you...

[Alexander Wuerstlein]

On 2014-06-27T19:21, ianG <iang at iang.org> wrote:
> So here's a merry puzzle.
> 
> Q1:  Case A:  Should crypto-security protocols in general always (MUST)
> include in-protocol negotiation to choose from a selection of ciphers
> and hashs and so forth?  This is commonly called "algorithmic agility".
> 
> OR, case B:
> 
> Should this not be compulsory (MAY) and some protocols could then impose
> by specification a single ciphersuite to be used?  One, only!  E.g.,
> ditch negotiation.
> 
> (And, it should be said, be limited to version upgrade in the event of a
> cipher break).  This is sometimes called "the one true cipher suite."

I would vote for Case A here since hashes regularly start to smell bad
(MD5, SHA1, ...) and ciphers also tend to do that sometimes (DES, RC4).
So some agility is necessary, and its absolutely necessary to have
options ready as soon as possible. Because in case of option B, one
would be limited to shrugging and continuing to use the broken "one true
cipher suite" since a) the committee won't decide (for years, see any
protocol committee) on "the non-broken second true cipher suite" and b)
it would be a totally new protocol so no vendor would support it within
a few years (see the abysmal state of TLS versions' implementation...).
And c) since negotiation is not an option, everybody would be stuck with
shitty crypto since you don't have the option of agility to at least
provide adequate crypto to the (perhaps few) modernized clients that can
support the new suites. 

> Then, Q2:  Same question but for the specific protocol of TCP-extended
> to offer opportunistic encryption.
> 
> That is, case A is to MUST have algorithm agility in the TCP-enhanced
> mode, and case B is to select a single ciphersuite and be done with it?
> 
> Case A:  32 flavours of icecream, and 29 toppings!  Case B:  You get
> vanilla.  Be grateful.

What good is the opportunity of encryption without the opportunity of it
being secure? Case B will degrade to "opportunistic ROT13" at some point
which means everybody will disable it because it only adds useless
overhead. I'd rather design something that has at least the chance of
being a bit longer-lived than the cipher-suite-du-jour, so Case A would
be my pick even in this situation.


That being said, in both Q1 and Q2 Cases A should only include
state-of-the-art crypto. Which would imho mean not copying the current
TLS cipher suite "telephone book" and also not adding anything that
might even be remotely insecure. So no 3DES, no NULL cipher, no CRC32
(*cough*), etc.


Ciao,

Alexander Wuerstlein.