Hash: SHA1

On Sep 5, 2013, at 8:02 PM, Jerry Leichter <leich...@lrw.com> wrote:

> Perhaps it's time to move away from public-key entirely!  We have a classic 
> paper - Needham and Schroeder, maybe? - showing that private key can do 
> anything public key can; it's just more complicated and less efficient.

Not really. The Needham-Schroeder you're thinking of is the essence of 
Kerberos, and while Kerberos is a very nice thing, it's hardly a replacement 
for public key.

If you use a Needham-Schroeder/Kerberos style system with symmetric key 
systems, you end up with all of the trust problems, but on steroids.

(And by the way, please say "symmetric key" as opposed to "public key" -- if 
you say "private key" then someone will inevitably get confused and think you 
mean the private half of a public key pair and there will be tears.)

> Not only are the techniques brittle and increasingly under suspicion, but in
> practice almost all of our public key crypto inherently relies on CA's - a 
> structure that's just *full* of well-known problems and vulnerabilities.  
> Public key *seems to* distribute the risk - you "just get the other guy's 
> public key" and you can then communicate with him safely.  But in practice it 
> *centralizes* risks:  In CA's, in single magic numbers that if revealed allow 
> complete compromise for all connections to a host (and we now suspect they 
> *are* being revealed.)

I have to disagree. You don't need a CA. 

There's a very long rant I could make here, and I'll try to keep it a summary.

Much of the system we have is built needing CAs, but it was only built that 
way. A long time ago, the certificate structure we're still vestigially using 
had as one of its goals a way to keep the riff-raff from using crypto. I 
remember when I got my first PEM certificate, I had to send my blinking 
passport off to MITRE for two weeks so they could let me encrypt the crapola 
that was sitting on my disk unencrypted. It was harder to get a cert than it 
was to get a visa to Saudi Arabia! So much of what we would have encrypted we 
just printed on paper and put in a file cabinet. Excuse me, I'm starting on 
that rant I said I wouldn't do.

The major problem one has with public key is knowing that the public key of the 
endpoint you want to talk to us actually the right public key. Trusted 
Introducers of any sort are one way to solve the problem. CAs are merely an 
industrialized form of Trusted Introducer and not ipso facto bad. The way that 
"Web PKI" (as it's now being called) is using Trusted Introducers is 
suboptimal, but ironically, we are on the inflection point of a real 
honest-to-whomever fix to them in the form of Certificate Transparency. That 
suggests even another discussion, one that I promised Ben I'd get to eventually.

The major problem with the certificate system is actually the browsers, in my 
opinion, because they actively discourage using certificates in any other way. 
If browsers, for example, allowed you to use a private cert with a user 
experience that was ultimately SSH-like (also called TOFU for Trust On First 
Use) as opposed to putting big blood-red danger warnings up, it would work out 
better for everyone including the CAs.

But anyway, there are other solutions. They range from some variant of Direct 
Trust being TOFU or even using a Kerberos-like system to hand you a key, or 
what we do in ZRTP, or lots of other things. 

The bottom line is that if you want to send someone a message securely and you 
have never talked to them before, you have no other way to deal with it than 
public key systems. 

(Or you can re-define the problem. Suppose I want to send Glenn Greenwald a 
message and his Kerberos controller gives me an AES key, I merely have to trust 
the controller. If we say that trusting him is the same as trusting the 
controller, then yeah, sure, it works. That's a suitable redefinition in which 
the KDC is isomorphic to a CA. But if we allow public key, then I could get Mr. 
Greenwald's public key from an intermediary who is not necessarily an 
authority, or even self-publish keys. It's done with PGP all the time.)

> We need to re-think everything about how we do cryptography.  Many decisions 
> were made based on hardware limitations of 20 and more years ago.  "More 
> efficient" claims from the 1980's often mean nothing today.  Many decisions 
> assumed trust models (like CA's) that we know are completely unrealistic.  
> Mobile is very different from the server-to-server and dumb-client-to-server 
> models that were all anyone thought about the time.  (Just look at SSL:  It 
> has the inherent assumption that the server *must* be authenticated, but the 
> client ... well, that's optional and rarely done.)  None of the work then 
> anticipated the kinds of attacks that are practical today.

I concur that the way that browsers and web servers us SSL is suboptimal. This 
doesn't mean that a solution is impossible, it only means we have a 
widely-distributed suboptimal system.

> I pointed out in another message that today, mobile endpoints potentially 
> have access to excellent sources of randomness, while servers have great 
> difficulty getting good random numbers.  This is the kind of fundamental 
> change that needs to inform new designs.

I have to disagree on that one, too. The servers that have problems indeed have 
problems. Servers do not implicitly have problems. The solutions are not evenly 
distributed, but they're not architectural. Heck, a Raspberry Pi has a hardware 


Version: PGP Universal 3.2.0 (Build 1672)
Charset: us-ascii

The cryptography mailing list

Reply via email to