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

[ianG]

On 29/06/2014 19:43 pm, Alexander Wuerstlein wrote:
> On 2014-06-29T17:02, ianG <iang at iang.org> wrote:
>> Hi Alexander,
>>
>> fun debate
> 
> I hope so, it would be a shame to just repeat your WW3 ;)
> 
>> 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.
> 
> Generally admins I have observed fall into 2 categories:
> - The ones who never would have cared anyways, switch on https only
>   because the boss ordered it. They use the first HOWTO that Google
>   finds and leave it at that. You can only get them to change a config
>   if you bother them enough.
> - The ones who care about encryption. They are happy to find out stuff
>   like [ach] exists and are generally grateful for professional guidance
>   in this rather complicated area.
> 
> I think the ratio of both groups is about 50:50. But maybe some kind of
> questionaire or a bit of research in that area could provide useful
> insights.


If the number of sysadms who care is high, then they will read the
Better Crypto doc, and that means a good impact.  OTOH, if the number of
sysadms that are effected is low, that means we'd be better off using
our time in other directions.  Either way it would be good to know.


>>> 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?
> 
> Usually because changing the config string is easier and cheaper.
> Sometimes you don't loose certifications because the version string
> won't be different. Sometimes you don't pay for a software upgrade. 
> Changing a list of ciphers is also unlikely to incur semantic changes
> that a protocol replacement could cause.
> 
> And since we are talking about changing your TCP implementation here,
> the change will be an operating system update which usually will cost
> you money and bring along a lot of additional pain. Far more money and
> pain than e.g. a simple Firefox Upgrade that brings you TLS1.2.
> So while I agree that it is perhaps unlikely that people will change
> their configuration, it is far more unlikely that they will update their
> OS.


I think when it comes to the vast population, that is what they do:
upgrade their OS using the auto-update button provided ... or perhaps I
am biased by Macs, but maybe that is also the point:  what is winning
and is seen to be winning is the OS that makes upgrades easy and timely.


>>> 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?
> 
> Well, yes, you can save one negotiation step and have one less degree of
> freedom. Which is good. But you also change have to consider that you
> are maybe changing protocol semantics along with the cipher suite which,
> depending on the changes, will be a problem.


Point here might be that upgrading a cipher, for no other benefit, seems
a waste.


> I think this model is acceptable, as long as there is a clear consensus
> that protocol updates for new cipher suites should be agreed upon in a
> very timely fashion. This would also mean that there could be version
> upgrades that just change the cipher suite and nothing else, perhaps
> skipping ahead of a queue of other nifty features that were planned for
> the next new version.


I think this assumes that the user / sysadm has anything to do with a
consensus.  I don't follow that assumption.  The last N times I updates
anything on my laptop, I didn't have much of an idea what was being
updated, I just updated to stop the silly warnings and questions about
UPDATE NOW or LATER.


>> 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 :)
> 
> Yes. Not talking at all to certain clients would mean refusing customers
> which would be unacceptable to most. Which is one of the reasons so many
> smelly ciphers were in use for such a long time in SSL. Maybe in
> TCPcrypt it will be different just because its OE and there is a
> transparent fallback to plaintext?
> 
> One slightly different and maybe offtopic question would be: Would OE
> lead to people getting careless about encryption and maybe skip
> mandatory encryption like TLS when they should really have used it?


The mere existence of TCPcrypt and OE would seem to suggest, yes.  Have
a look at HTTP.  It's unencrypted.  People were asked to "upgrade" to
HTTPS if they wanted encryption.  They didn't, at a 99% ratio.

Of course, pundits suggest that's because they didn't want encryption.
I'm not so sure.  Anyone who's ever watched ordinary users try and get
HTTPS going on their website has a different view.  I prefer to take
such decisions completely out of the hands of users.



iang