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

[ianG]

So here's a merry puzzle.

Over at IETF, they are trying to create an extension to TCP that
opportunistically leaps with gay abandon into encryption mode.  Bless
'em!  This means, if both ends have the extension, TCP will be
encrypted, and the devils of mass surveillance will be thwarted.  Yay!

However, as with every committee product, the room has bifurcated into
WW3 over a question.  Here is the question over which the two sides
duel, in two parts, perhaps to tease out just how deeply y'all feel here.

Given that this very room has now battled for 6m on producing the mother
of all security guides, I'm guessing there are some opinions ;)

Here goes:




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





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.




iang