<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 Sun, May 16, 2021 at 5:41 PM jrzx via cryptography <<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.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 Saturday, May 15, 2021 6:56 PM, John Levine <<a href="mailto:johnl@iecc.com" target="_blank">johnl@iecc.com</a>> wrote:<br>
> Once again, this is an Internet very much unlike the one<br>
> the rest of us use.<br>
<br>
> For my bank, the bank is in upstate NY but all of their<br>
> web sites are handled by their contractor somewhere in<br>
> the midwest, and I am quite certain the contractor<br>
> manages the SSL certs,<br>
<br>
You may be certain, but I see no evidence for your certainty<br>
in their certs.<br>
<br>
And if their contractor does indeed control their secrets,<br>
then were he to stuff their certs into a CDN, which he did<br>
not, then not only would their contractor have control, and<br>
they not have control, but no end of unknown people and<br>
machines between the machine servicing their web pages,<br>
and the machine holding the secrets controlling their<br>
certs, would also have control.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Security has no ideology. If it did, it would hardly choose a synthesis of Trotskyite and Libertarian ideologies.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Security is about risk control. John is making an argument about control of specific risks. John has an asset (funds in the account) which are protected by various controls, among which are the WebPKI controls that assure him that the Web site through which he interacts with his bank is the one he expects. The risks of a WebPKI failure is really not relevant to that interaction, an EV cert is adequate to give the necessary level of assurance. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">There are many, many aspects of online banking that are unsatisfactory that are in the power of Google to fix. The real weak point in online banking is that the passwords are transmitted to the site for validation rather than a proof of knowledge of the password being used such as the one I designed for HTTP in 1993.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But bleating on about the insecurity of other providers is so much easier than fixing the stuff that matters. The WebPKI is designed to do a particular job which it does almost flawlessly. The fact that it does not perform every task that people might want it to is irrelevant, it does its job as it is supposed to.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I played a part in building the WebPKI, I designed the assertion infrastructure of SAML, both work well for the purposes that I designed them to serve. If you would like to apply PKI to other problems then why not take a look at the work I have done since that is designed to meet many of those concerns?</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">HTTP+TLS is a good solution for the specific problem of protecting browser interactions. It is a lousy solution for transactional and telemetry interactions. I have spent the past couple of months focused on that issue with RUD and the number of glaring omissions in the existing approach is interesting.</div><br></div><div><br></div><div> </div></div></div>