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

[Alexander Wuerstlein]

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.

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

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

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.

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



Ciao,

Alexander Wuerstlein.