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

[ianG]

On 27/06/2014 18:49 pm, Alexander Wuerstlein wrote:
> 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).


OK, Case A.  I asked :)


I think I would quibble on the logic tho.  MD5 was effectively
outclassed by SHA1 in 1995 or 1996.  There was then an 8 year period
during which we were supposed to switch over.

DES started to look weak early 1990s, and indeed its 56 bit key was
decidedly weak by design.  With things like IDEA and blowfish, we knew
we could do better.  It was eventually crunched late 1990s.

RC4 has been in the doghouse for at least all the 2000s.

So, why don't people switch?  I think it is unfair to say "regularly."
The average warning time here or smell time is a decade.  But people
don't switch...

This I think reveals (a) another problem and (b) undermines any case
that agility can help.  Indeed, does the agility reveals the reverse, a
method to keep using smelly algorithms, not a method to get rid of them?


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


But that sounds like the case now :)  We've got agility in SSL, we went
back to RC4.  What's going on here?


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


well, the notion is that Case B will be assisted by a version upgrade.


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


Part of the argument for agility is the ability to use national
favourites, hardware specials, etc.  Once that door is open ...

iang