[Cryptography] WireGuard

[Jerry Leichter]

> The problem with a lot of the approaches is that the folk proposing them start from the objective of eliminating all dependence on third parties, not minimizing risk.
> 
> Governments are bad, CAs are bad, yak yak yak, chunter, chunter, chunter, etc. etc.
> 
> The Web PKI was designed to authenticate and authorize Web sites. The encryption part was merely a byproduct. The original design brief was to make shopping online at least as secure and convenient as offline....
I think much of the confusion is based on not identifying the problem to be solved.

The whole mechanism of CA's attempts to solve a very specific problem:  Establishing a secure channel between parties that have never communicated before.  Or, drilling down a bit more, ensuring the identify of a counterparty you've never communicated with before.

We all know the limitations of a key agreement protocol like (anonymous) DH:  Alice can establish a channel to Bob that's secure against anyone else, but without some way to identify Bob as the party at the other end, that's not a very useful thing to do.

The whole issue in SSL came down to:  I want to connect to this Amazon company I've heard about, but how do I know it's *the* Amazon company and not someone faking it?  Well ... Amazon gives me a certificate attesting that it is indeed Amazon.  And I trust that certificate because a CA certifies that it's valid.

In fact, if you look at the other side of the connection, it works pretty much the same way.  Amazon is willing to send me goods in return for my presenting a "certificate" in the form of a name and credit card number, which Amazon trusts because some CC clearing agency house certifies that it's valid.

Could this really have been otherwise?  All remote business transactions work in exactly this way.  They always have:  Someone already trusted acts as an introducer.  The only alternative is direct one-to-one contact and barter.  (How is actual cash different from a counterfeit other than in having a "signature" from the government....)

How did you know, when you went into a real-world Macy's, that it really *was* a Macy's?  Well, building a whole store to look like Macy's would be very expensive - and someone would notice and Macy's would come after the fake.  So it wasn't worth doing - most of the time.  (There were fake Apple Store's, selling fake Apple goods, in China a number of years back.  In some cases, not even the employees in the stores knew that the store was not, in fact, associated with Apple.)

You can distribute the introducer using something like blockchain - though if you think about it, you're still relying on whoever put the blockchain entry saying "you can get to Amazon with this key" - and you really don't know who that might be.  What a public attestation like this does is allow Amazon to notice if someone is acting in its stead.  Enter Certificate Transparency.

I've previously suggested that since you must inherently trust your browser maker - if he spikes your code, it doesn't matter how you get keys - so it would make sense for browser makers to also be "CA"'s - though if they do that they could as easily hard-code in actual keys.  That's not how the Web evolved - for many reasons - and is unlikely now.

Once an initial contact and exchange of identities has occurred, sure, you can exchange secrets and on the next contact be assured that you're talking to "whoever it was I trusted to be Amazon the last time we spoke".  Different problem, different (potential) solutions.

Where one might criticize SSL/TLS is its reliance on certificates *exclusively*.  The second time I contact Amazon, I might well prefer to rely on my records from the first time.  Why bring in a CA?  If you drill down into this, all kinds of interesting issues emerge.  Yes, it requires both me and Amazon to keep state around.  In fact, Amazon does want me to have an account, and it's keeping a whole bunch of state around - but it in some sense doesn't trust that state:  Even if it has my CC information, it will check it again the next time I try to buy something.  And every browser since the very earliest ones has kept around a memory of sites to which I've connected in the past.  All modern ones can also keep around the authentication information (account name and password) so that I can authenticate to Amazon - but, because SSL/TLS relies on certs exclusively, *not* the information needed for Amazon to authenticate to me.  Curious, when you look at it that way.

BTW, I run into this issue in a real way in my day job.  I work on software that runs within datacenters.  Within a datacenter, most systems don't even have DNS entries - they just have 10.* addresses.  Customers want connections between their systems to be "secure", which in policy terms ends up requiring TLS.  How do you set up TLS connections between systems with no DNS entry and a 10.* address?  Who would give you a certificate for such a thing?  (If you can find someone, they shouldn't be in the business!)

In practice, everyone uses self-signed certificates.  This is getting more and more interesting "on the edge", where browsers are making it increasingly annoying and difficult to connect to a server using a self-signed certificate....

SSH-like protocols give you the raw data needed to solve the first connection problem - the fingerprint of the remote party - but leave all the rest to you.  In practice, no one checks - the problem is "solved" by ignoring it.  Has this led to attacks?  Certainly, though I don't recall any being reported or discussed publicly.  The whole thing is viewed through the lens of "caveat emptor" - "I have only myself to blame" for not checking.

Are SSH-like protocols more or less secure than CA-based protocols?  It depends.  An SSH-like protocol requires trust in some kind of external (perhaps third party) verification on first connection.  The trust extended (and perhaps breached) at that point covers all subsequent communications.  The SSL/TLS model requires trust in the entire certificate system for each connection, forever.  Which is "more secure"?
                                                        -- Jerry



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180903/a3063974/attachment.html>