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

[ianG]

Hi Alexander,

fun debate



On 29/06/2014 14:30 pm, Alexander Wuerstlein wrote:
> 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.


Right.  It's costly for people to switch, both to decide and to do.
Better to do nothing.

Unfortunately all these costs hit the agility equation as well; the
notion of agility seems to assume that there is a tribe of sysadms
hunting around for older config strings and replacing them with this
month's flavour.

Perhaps [ach] is in a good position here -- what we could ask is what is
the exposure / effect of the good bible.  How many people have seen it,
what proportion have made a change, what proportion have not?  Questions
like that.


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


Right.  It is my thesis that once something is set, it is never touched.
 If it ain't broken, don't fix it.

The exception to that is upgrade by complete replacement (buy another
laptop) or by software managed upgrade cycles (apple and some apps).

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


Right.  But it if is not possible to get people to hit the upgrade
button, how is it possible to get them to change the config string?


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


Canonically, protocol upgrade SSL v2 -> v3 -> TLS v1.0 -> 1.1 -> 1.2...

And, this will be organised by your OS vendor, but it Apple or Microsoft
or Android (!).

Each version upgrade can deal with its own version and ones past.  So
e.g., TCPcrypt v 6 can deal with versions 6,5,4.  Say.

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


Conceptually yes, we are in the same conceptual place.  But the
engineering issues differ greatly.

We always need protocol upgrade.  We always must have v1 through N
capability.  vN will always have to talk to vN-1, etc.

So why not use it instead of having this internal vanity discussion
called cipher negotiation as well?


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


Forcing all your old clients to use plaintext is possibly the least
damaging compromise.  So for example I would say that when v6 is talking
to v3, it might decide not to talk.

And yes, we can have this argument differently for TCPcrypt and for SSL.
 Which is why I asked in two parts :)


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


The current political move is specifically oriented to mass
surveillance.  However, I would say this:  we do what we can for free.
If we can knock out 1. above as well, I'm all for it.  If we can knock
out only 2. above then that's still a massive benefit.


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


Hugely.  They will have to target.  Instead of hoovering, they will have
to launch a targetted and injective attack.  This means leaving traces;
 procedures;  law;  target prioritisation;  collateral damage, etc.

Consider the situation now.  They have *all* your comms.  Now you get
into an argument with some dumb FBI agent at the airport.  He phones up
his buddies in the interagency task force and reports you as a potential
terrorist and gets a hot feed to all your data.  Finds out about your
embarrassing blah blah and sticks it to you.

We know for example that the western wall between intel and police is
now a thing of the past.  We know that corruption of the police has been
going on since WoD.  And we know how third world police use their jobs
as shakedowns.  Seems like we don't want that to happen on a mass scale.

So, definitely, we want an end to mass surveillance and we want to force
the police to have hurdles so they can target bad guys not shakedowns.


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


Well, we never get rid of the negotiation problem, as far as I know all
protocols will handle different versions.


> or it will leave clients unencrypted unnecessarily.

Ah, this is a likelihood question.  What is the likelihood of a cipher
breach leading clients unencrypted unnecessarily?  Short answer, zero,
historically it has not happened in recent times.

What is the comparitive likelihood of a complicated but agile protocol
leaving clients unencrypted /versus/ a simple but unagile protocol?

I'd say 10 times.  In the case of HTTP, it's 100 times, as HTTPS only
reaches 1% of traffic.  IPSec, probably 1000 times?

So, which battle are we fighing here?



iang