Microsoft files EU Android complaint

[D. Hugh Redelmeier]

| From: James Knott <james.knott-bJEeYj9oJeDQT0dZR+AlfA at public.gmane.org>

| D. Hugh Redelmeier wrote:

| > One automatically thinks choice is good.  But for interoperation, it
| > just isn't.  We want everyone to have a common
| > encryption/authentication/privacy/security/... so that they can
| > interoperate.

| > In IPSec, a lot of the interoperation rigmarole that makes it hard to
| > set up is
| > (a) the options, and
| > (b) the awkward ways to configure most implementations, and
| > (c) the awkward way that IKE negotiates.
| >
| > IKEv2 was meant to address this but I don't know if it succeeds, and
| > it isn't generally used.
| >
| > Combinatorial complexity of a program makes it very hard to test all
| > cases.  This is VERY bad from a security standpoint.  Options create
| > such combinatorial complexity.
| 
| IPSec has been in use for a while and seen a lot of testing.  There are
| different ways to configure it.

Yeah.  Been there and got the teeshirt (literally: I've been to
several "VPN Bakeoffs" back in the day, and we always got teeshirts).

Testing can never show the absence of bugs.

Interoperating during testing involved too much shouting back and
forth about settings.

User interfaces bore too much similarity to DIP switches.

Example:
The order of most IKE payloads is unspecified.  For a long time, we
only accepted them in one order (that in which they were described in
the RFC).  Never once did that cause a problem.  I would guess that
many implementations would fail if they received payloads in another
order.  This is an example where the spec gave an option that was
worse than useless (at least it wasn't visible to the user).

I would bet fuzzers would find bugs in most implementations (they did
in ours).

|  For example, I have used shared secret
| passwords with several VPNs,  You can also use public/private keys, in the
| same manner as ssh, certificates, as is used with several services or a key
| server.  IPSec supports them all and you choose which ever is best for the
| application.

I think that I'm the only one that implemented IKE authentication with
bare public keys (i.e. not embedded in X.509 certificates).  Too bad.
I once bought a Linksys wireless router because the manual said that
it had this feature.  But the GUI didn't implement a way to use it
(even though it was documented) so it didn't work.  This was GPLed
code and they wouldn't respond to my requests for the source (either
as a customer or the copyright holder).  Grrr.  (The router was quite
buggy; if they'd been more open, the community would likely have fixed
the problems.)

In any case, I think some options are worthwhile, some not.

Lots of people want pre-shared keys but bare public keys are just
about as easy, way more powerful, and easier to handle safely.
Example: it is safe to distribute your public key in public -- try
that with your pre-shared key.  So perhaps pre-shared keys should not
be an option.

We fought for a long time to get DES eliminated (it had been mandatory
to support it in IPSec).  Our sponsor even built the DES-cracking
hardware to make the point that DES was too weak (up to then denied by
NSA, even to the US Congress).

(strongSwan, Openswan, Libreswan are all continuations of the (dead)
FreeS/WAN project.  I think that Openswan is unlikely to move forward
since the main contributors have started Libreswan.  I help the
Libreswan project a bit.)
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists