[Discuss] Why the dislike of X.509?

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

On Mon, Aug 25, 2014 at 5:28 PM, Bill Bogstad <bogstad at pobox.com> wrote:
> I think there are still some significant differences between key escrow and
> a X509 PKI system.   Please correct any errors.

> Key Escrow - Holder of Key can read all your old messages, read any new
> messages you create, and pretend to be you in a way that is
> indistinguishable? from your own signing.

Strict interpretation / definition, you are correct.

I think Rich is using it slightly metaphorically, referring to any
situation where a central authority has too much of a backdoor and
ability to forge/frame identity.


> X509 PKI - Holder of a CA can't read old messages you sent, can't read any
> new messages that you send,

If properly implemented. Public CAs mostly are.
[ Lazy implementation where IT Central private internal PKI generates
the two-part key and then signs both parts and delivers bot to the
admin installing it is in a state of crypto sin. Never move private
half of an asymmetric key. This may be done when IT Central feels the
need for key recovery but also just to assure Standards. ]

>[CA] can pretend to be you (but with a key that is
> different from the one that you are using).  The pretending to be you is a
> bit like the you/evil twin thing.

Correct.
As can anyone who can social-engineer the CA or any other CA into
signing a new key with same ID too.

>  Recipient can't tell which one is the
> real you, but can tell that two different entities

No they just know there are two keys.
The null hypothesis that one real entity has two keys is not ruled
out, and is common !

> are trying to claim to be
> you based on the CA that they are using.  (Okay if they compromised the CA
> that you actually used, that may not be true; but lets assume they
> compromised Certs-R-Us instead of whatever ultra-secure CA that you used.)

They can at least (theoretically) tell you "changed" your cert.
If they keep track.
PGP users would notice a key not in their keyring and perhaps look for
signatures in web of trust.
But what apps using CA roots check for cert changes ?

Now switch 'you' and 'recipient' and get worried.
What if the forged cert isn't yours but is for a website (or HTTPS
proxy for other service eg VPN) that you are attempting to contact
securely?

Can i tell if the website i am talking to is real or a
man-in-the-middle installed by someone who owns or pwns the local
router/ISP?
HTTP padlock lights up green, i'm good, right ?
Uh, not if they got a good green-level spoof cert for mail.google.com
*.google.com or *.com to use when they intercept my traffic.
Or if i don't notice it's gold not green today; gold used to be good enough !

On Web, real companies *do* have certs from multiple sources in use
simultaneously, e.g. during transition or due to build out phasing.

I tried turning on a plug-in that warned whenever the Cert for a given
address changed from prior contact, to add a test for just this
attack.  Google has such a widespread perimeter server farm that it
became unusable, as i got a different cert with every session. False
positives completely swamped any actual signal.

> Now while I see that PKI has issues, I think it is a little much to claim
> that it is as bad as PKI.   Or maybe I'm missing something.

PKI with hundreds of roots + DNS spoof + BGP spoof + vulnerable
routers all over = big trouble.
(PKI with single root is different problem.)
L7 end to end payload encryption (PGP, S/MIME) can help, since App can
reject garbage even if connection was secure.

   The ability to create Man In The Middle attacks dynamically lets
one capture new sessions, which is good enough for many Aggressor
purposes. It's not a perfect Key Escrow, it doesn't let one recover
OLD messages not through a MITM, but it also doesn't require the
storage/retrieval of total Key Escrow. Can dial it up on need, much
more efficient.

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