[Discuss] Why the dislike of X.509?

[bill.n1vux at gmail.com (Bill Ricker)]

On Mon, Aug 25, 2014 at 2:20 PM,  <markw at mohawksoft.com> wrote:
> You are talking about browser fuckary, not openvpn. Openvpn uses the
> hierarchical PKI of x509, but has no default "trusted" CAs.

That a VPN doesn't require or apparently use the installed 'default
"trusted" CAs' doesn't necessarily mean it successfully ignores them.

If it uses the same SSL library as a browser -- on any platform --
that assertion has to be demonstrated to be true.

I hope you're right.  Hope is not good enough to a security auditor. Show me.

I share Rich's concern about Key Escrow anytime, anywhere, and
understand why VPN and/or PKI smells similar to him.

But If Rich is worried about a private corporate self-hosted OPEN-VPN
implemented with self-signed local-root CA key acting as key escrow,
well, that is irrelevant for VPN use-case WHEN (actually) PRIVATELY
HOSTED.
   (Aside from my hypothetical inadvertent public root trust concern.)
   Yeah, you trust the Admin admin running it, who gen'd and
self-signed their key and your key too, and the Corp that owns it.
Your bits go to their server eventually when you VPN into them anyway,
so why not?
   If Corp VPN and users exchange secret keys out of band instead of
issuing client&server private PKI x.509 certs out of band, the Corp is
still in position to cough up everything.
   If the Corp node in the VPN is subverted or subpoenaed, the traffic
can be gotten at point of egress from the tunnel by the corporate
owner (or by subverted systems) even easier. VPN usecase does NOT
protect users from VPN host.
   (Likewise with unsigned SSH RSA keys, either end-point can spill
what's before or after the tunnel, and recipient Host can add bogus
keys to allow Eve to log in as Alice, just as Root can make a second
usernam/password with same numeric userid to read/write all your
files, if there isn't second-factor auth. )

But Rich is right that with Commercial  VPN providers (whether based
on OpenVPN or proprietary stacks), yes, the moral equivalent of key
escrow is a very real concern, whether X509 PKI or not, but X509
complicates matters. Need to find out in each case if the
nuts-and-bolts allow the Provider to answer a subpoena/NSL to cough up
keys or implement a MITM tap without help from each client Corp's
admin, if their PKI gives them back door, or if it requires customer
cooperation.

VPNs as a service have a big trust issue.
VPNs implemented locally are locally centralized. This provides a
single locus within the Corp for an opponent to attack by hack or by
legal pressure, but this Centralization doesn't intrinsically change
the trust model.
(unless you for some reason trust your local Root ops more than Corp
Network Operations, which would be a problem of another sort).
(and unless the product "implemented locally" uses a hardware Vendor
CA chain instead of truly local keying, in which case it isn't reall
local, see 'as a service' above !! )

Your bits travelling through employer are not totally protected and
never will be, even if some courts say you have an expectation of
privacy (for some purposes).
Your bits travelling through a Partner's system who gives (sells) you
VPN access into their systems for some mutual benefit aren't protected
from them after they emerge from the tunnel either, so their having
escrow-equivalent ability to recover/spoof/whatever your keying matter
is pretty irrelevant.
Both Employer and Partner entities will respond to Subpoena / NSL.
Nobody should expect otherwise.

(Which doesn't change that anything that smells like escrow smells
'off' to those who care about security that really works.  From what
Rich has said re dates, his allergy to escrow likely stems from the
same controversy as mine.
http://www.cryptomuseum.com/crypto/usa/clipper.htm
http://en.wikipedia.org/wiki/Clipper_chip#Backlash
   X509 PKI is not normally considered an escrow regime in normal
usage, but Rich is quite correct that central CAs or other registries
have *abilities* that are hard to distinguish from Escrow - even if
they never know your private key, they can at the very least forge
another one with the same apparent identity, and so spoof you to
others -- or spoof someone important to you.
   With a VPN or other Central registry that totally generates all
keying matter (rather than signing public half of pub/priv key the
client app creates), they may actually literally escrow too. But that
would be wrong.  Moving RSA-style private keys of an asymmetric
public/private is a mortal sin in cryptography; if you are sharing a
secret, might as well be a shared symmetric key. Multiple
Load-balancers all terminating connections for same public cert with
copies of a private  key is dubious practice.)

-- 
Bill Ricker
bill.n1vux at gmail.com
https://www.linkedin.com/in/n1vux