<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 14, 2020 at 4:43 PM Bill Frantz <<a href="mailto:frantz@pwpconsult.com">frantz@pwpconsult.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">On 2/13/20 at 6:40 PM, <a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a> (Phillip <br>
Hallam-Baker) wrote:<br>
<br>
>On Tue, Feb 11, 2020 at 7:43 PM Bill Frantz <<a href="mailto:frantz@pwpconsult.com" target="_blank">frantz@pwpconsult.com</a>> wrote:<br>
><br>
>>...<br>
>><br>
>>When you make good money selling certificates, you love the<br>
>>hammer you have.<br>
>><br>
><br>
>I think this is an unhelpful way to think.<br>
<br>
Phillip and I will perhaps have to agree to disagree. I have <br>
always objected to having to rely on a "Trusted Third Party" <br>
(TTP) to validate any web connection. When I deal with <br>
individuals and businesses outside of the computer <br>
communications world, I use the model of recognition, not <br>
attestation. I may buy something inexpensive to start developing <br>
trust in my counter-party. I'll use the physical location or <br>
face as an anchor for that developing trust, not a TTP.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">People have been complaining about my work for decades. The WebPKI met its design brief and it was deployed at global scale. The same cannot be said of any other alternative that was proposed.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The WebPKI design brief was very narrow, I know this because I wrote it together with Michael Baum, Warwick Ford. The objective was to make shopping online as safe for the customer as shopping in a store. That is all. Confidentiality was not a primary concern, that was a secondary concern necessitated by the fact that credit card numbers are bearer tokens.</div><br></div><div><div class="gmail_default" style="font-size:small">The WebPKI was designed as an accountability infrastructure. The goal being to ensure that if a merchant did not deliver, there would be consequences. The objective was never to prevent the possibility of merchant fraud, it was to limit the rate to an unprofitable level.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And the system worked so well fir the first decade, a lot of arrogant sods decided they knew better and could start hacking parts out arbitrarily. Like the revocation infrastructure. And then folk decided that it was an all purpose confidentiality infrastructure because that is the only type of security they can understand.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">People can ignore me if they like, but blowing off the anti-Trust concerns that drove Microsoft's contribution to the WebPKI is going to look like a terrible idea pretty soon. 'Big Tech' is becoming a slogan and not just on the far left, the GOP is actually rather more concerned. Facebook took their party away from them and gave it to Putin/Trump. The whip of choice will be anti-Trust and WebPKI will be just one of its tails.</div></div><div class="gmail_default" style="font-size:small"><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For the web, I would like to have my trust anchor for a site be <br>
through a key it controls, not a CA. When I go to a site using a <br>
CA as a trust anchor, I will keep my financial and secret data <br>
exposure low until I have some transaction experience. I want to <br>
know I'm talking to the same site I was talking to when I <br>
developed the trust I have, not a intruder site attested to by <br>
an untrustworthy TTP. (Do browsers still have over 80 trust anchors?)<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">The flaw in the WebPKI is that the design brief really calls for an introduction scheme and TLS is configured as a transaction authentication scheme. That is in part a consequence of not having the tools at the time to make an introduction scheme portable across browsers and hosts. It is also a consequence of the fact that a merchant does not necessarily defect immediately and it takes time for defection to be observed. Oh and the fact that many Web sites are incapable of managing PKI with the fidelity required for pinning trust anchors.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think we have the current system because that was the only <br>
system people could build a business model around, and that the <br>
need to support that business model was reflected in <br>
contributions to the standards bodies.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">The RSA and DH patents expired in the 90s, there was plenty of opportunity to propose something different.</div><br></div><div><div class="gmail_default" style="font-size:small">The problem is path dependence, not some conspiracy. We could have adapted TLS for IoT devices really easily, just make use of self signed certs painless. I suggested that on a half dozen occasions and it never happened. </div><br></div><div><div class="gmail_default" style="font-size:small"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>IoT needs a PKI. But PKIX has a bunch of assumptions built in that are<br>
>unhelpful (to say the least). Sure, we need something a bit different but<br>
>who is going to design and deploy that infrastructure?<br>
<br>
Phillip may have meant the following, but here's my take for clarity.<br>
<br>
It seems to me that an IoT device doesn't need a traditional <br>
PKI. It needs to validate the devices it talks to -- the light <br>
switch and the bulbs need to validate each other, which is <br>
better done through direct introduction. The phone app which <br>
allows remote control should be verifying the device using the <br>
public key pair built into it.<br>
<br>
When the IoT device talks to the mother ship to upload your <br>
behavior profile, it would be better to include the necessary <br>
public keys in the device when it is purchased.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">You can't trust manufacturer inserted device keys and they turn out to be a liability for the manufacturer - just ask Huawei. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The approach I am proposing in the Mesh is to use threshold key generation so that manufacturer installed keys are only ever used during onboarding. The administrator issues a seed from which a second keypair is generated deterministically and the sum of the two private keys is used for the private key of the device within a particular Mesh.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So if the built in device key is {d.B, d} where B is the base point and the administrator device provisions {a.B, a}, the composite key pair is {d.B+a.B, (d+a) mod Q} where Q is the order of the subgroup.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The really nice thing about this approach is that we don't (usually) need to worry about proof of possession. The admin device can calculate the public key of the device in the user's Mesh without knowing d. And that is what they credential. So the device can't actually make use of the composite private key unless they know d.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[Yes, there are some pitfalls to watch out for, this approach means that as far as external parties are concerned, the private key is at lest as strong as the stronger of the two key contributions. Unfortunately, the public key turns out to be as trustworthy as the least trustworthy of the contributions. Which leads to rogue key attacks...]</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div></div>