[Cryptography] WireGuard

Phillip Hallam-Baker phill at hallambaker.com
Tue Sep 4 10:56:42 EDT 2018


On Mon, Sep 3, 2018 at 7:16 AM Jerry Leichter <leichter at lrw.com> wrote:

> 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.
>
...


> 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....)
>
...

> 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.
>

Exactly my point. The pinning stuff looks like it was designed by folk who
start with the notion 'lets shoot all the lawyers (CAs)'.

That has not been a very productive approach in the 30 years we have been
doing commercial PKI. I have a similar problem with Blockchain, instead of
reforming how we exchange money and make that cheaper, BitCoin attempts to
redefine what we mean by money.

Security is always a property of a system and never a property of a
component in isolation. It is trivial to solve almost any security issue in
isolation. So when people are talking about 'implementation details' they
are ignoring the fact that it is all the details that are the issue.

I am pretty sure that when we get hold of the NSA BULLRUN manual it will
say something like 'identify key details that will render the protocol
unusable if neglected, use your influence in the working group to ensure
that they are neglected and work to isolate and marginalize WG members who
demand they be considered'

It wasn't just myself who was made unwelcome in the DANE WG, they also made
sure Ben Laurie at Google knew his input would be ignored and made sure
nobody from Microsoft or Apple was involved. So they ended up with a spec
nobody will ever implement but will squat on the 'security policy in DNS'
slot until someone deploys something ignoring the DANE work. The same
individual who made sure DANE went down that path did the exact same thing
on DPRIV. Now I am not saying he was the NSA mole but he was almost
certainly one of the people the NSA mole knew to manipulate.


I don't think the NSA is doing that any more as it is realized that the US
lives in an impressive glass house and the cyber command operations are
throwing stones. There is never going to be a return to the 1953-1973 era
when the NSA ability to break mechanical ciphers allowed the NSA/CIA to
stage coups from Iran to Chile. Blocking deployment of strong cryptography
left the US vulnerable to Putin's attacks.

What should we do instead? Well first, we should define ONE way for an
Internet client to discover an Internet service and associated description.
Most of this work is already done by Stuart Cheshire and Co at
Apple [RFC6763]. I describe how to apply this to Web services here:

http://mathmesh.com/Documents/draft-hallambaker-json-web-service.html

DNSSEC is an absolutely rotten trust infrastructure as there is only one CA
and it is vulnerable to being ordered to defect by one nation state. But if
you ignore the issue of who signs the root and TLD zones, it is pretty much
OK for the purpose of signing SECURITY POLICY.

"Always use TLS 1.2 or higher"
"Certificates MUST be validated under trust roots A AND B"
etc.

To address the problem that ICANN can't be trusted, see Strong Internet
Names.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180904/bf61e0de/attachment.html>


More information about the cryptography mailing list