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

[Alexander Wuerstlein]

On 2014-06-29T13:05, ianG <iang at iang.org> wrote:
> 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).
> 
> 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?

I think people don't switch because of the general tendency to keep
using old stuff as long as possible: Take Windows XP and 2003 as an
example for "why don't people switch off RC4 and 3DES?". The reason to
stick with WinXP of course being the cost (in money, time, manpower,
knowledge) of migration and perhaps the cost of new hardware or software
that that migration makes necessary.

That example also illustrates that a decade will always be your "smell
time interval", because that is the usual amount of time from the begin
of implementation of a new protocol/ciphersuite in some software or
library until the end of support. And sometimes the begin of
implementation will be a bit late since software vendors are often lazy
with non-shiny features like supported crypto protocols (see TLS
support in Mozilla). All of this is your "(a) another problem".

Agility will not solve this general problem of old software. I'm not
sure if it is possible to force people to update more often through a
protocol specification.

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

What kind of version upgrade?

The problem is that you would either introduce another kind of
negotiation and agility in the protocol version. Which by proxy would
mean that you still negotiate the cipher suite, so you are still in Case
A, only by a different name.

Or you have an incompatible version upgrade which would mean "take the
new version or leave it and use plaintext" in case of opportunistic
encryption. Which means that in case of a version upgrade, you force all
your old clients to plaintext. Since its "only" about opportunistic
encryption anyways one could argue that this is acceptable behaviour.

There is also the question as to the threat this opportunistic
encryption should protect against. 1. Snooping by an the
neighbours kid via WLAN? 2. The NSA tapping wires?

If its 1., then maybe smelly crypto is still good enough. If its 2.,
then there is the question of "how will OE help against such an
opponent?".

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

Yes, that argument can work both ways and I see your point that if one
can limit the amount of cipher suites by coupling one cipher suite with
one protocol version. But that will either not get rid of the
negiotiation problem or it will leave clients unencrypted unnecessarily.



Ciao,

Alexander Wuerstlein.