<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 3, 2018 at 7:16 AM Jerry Leichter <<a href="mailto:leichter@lrw.com">leichter@lrw.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><span style="font-size:small">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.</span><br><div><div dir="ltr"><div style="font-size:small"><br></div><div style="font-size:small">Governments are bad, CAs are bad, yak yak yak, chunter, chunter, chunter, etc. etc.</div><div style="font-size:small"><br></div><div style="font-size:small">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....</div></div></div></blockquote>I think much of the confusion is based on not identifying the problem to be solved.</div><div><br></div><div>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.</div></div></blockquote><div><div class="gmail_default" style="font-size:small;display:inline">...</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>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....)</div></div></blockquote><div><div class="gmail_default" style="font-size:small">...</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Exactly my point. The pinning stuff looks like it was designed by folk who start with the notion 'lets shoot all the lawyers (CAs)'. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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'</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><br></div><div class="gmail_default" style="font-size:small"><br></div><div><div class="gmail_default" style="font-size:small">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.</div><br></div><div><div class="gmail_default" style="font-size:small">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:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><a href="http://mathmesh.com/Documents/draft-hallambaker-json-web-service.html">http://mathmesh.com/Documents/draft-hallambaker-json-web-service.html</a></div><br></div><div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">"Always use TLS 1.2 or higher"</div><div class="gmail_default" style="font-size:small">"Certificates MUST be validated under trust roots A AND B"</div><div class="gmail_default" style="font-size:small">etc.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">To address the problem that ICANN can't be trusted, see Strong Internet Names.</div><br></div><div><br></div><div><br></div></div></div></div></div>