On Tue, 2024-08-13 at 10:49 -0400, Phillip Hallam-Baker wrote: > Nick raises some good points. The WebPKI was originally designed with > a very specific purpose and working within the limits of the machines > of the day. 30 years later we are using it for completely different > purposes. > > Back in 1995, strong encryption was subject to export control. > Confidentiality was limited to a 40 bit work factor. The WebPKI was > not designed to support confidentiality, it was an Authentication and > Authorization infrastructure. The goal being to make shopping online > with your credit card as safe as shopping in a store. > > Confidentiality would have been much easier. Don't really need the > certificates at all, can use TAFU like SSH does. The complexity came > from the need to revoke credentials for fraudulent merchants. But > path dependence is a real thing in standards. I would add that SSH Clients also *remember* the server's fingerprint, thus, provided that you reach the real server the first time you connect, you will be warned by the SSH Client if the server fingerprint has changed. > > The simplest fix for the issue Nick raises would be for browsers to > silently accept self-signed certificates and turn on encryption > without notification to the user. I am aware this creates a MITM > issue but that is better than no encryption at all which is what most > IoT devices end up with. > > Lets Encrypt has done some great things but it isn't really an IoT > solution as the device has to have a DNS name and that has to be > validated to the public key. Most home users don't have a DNS name > and so IoT fails. > > How could we do things differently? I do have a proposal and I do > have running code, drafts and quite a bit else. I will be making some > videos soon. > > First change in perspective I think is needed is the WebPKI mediates > every transaction which was necessary because we were telling users > which merchants were safe and which were not. For general Web > browsing and IoT, the Trusted Third Party should be an introducer > rather than a mediator. Or at the very least, the roles should be > separated. I agree with this. We should separate protection from eavesdropping from verification of a business. I also think browsers should educate users about TLS, because right now, their error messages are more fear-mongering than truth. While this is not what I had in mind as a proposal, I think it would be good if browsers, as a stating point, simply had "security levels" with agreed upon icons, colors, and requirements that all browser vendors followed, and educated users on their meaning. For example, a colored lock icon with a number inside of it: (1) - This connection does not use encryption. (2) - This connection uses a self-signed certificate that has never been encountered before. (3) - This connection uses a self-signed certificate that matches the fingerprint from the last time you connected to this site. (Trust level is bumped due to consistency of fingerprint). (3) - This connection uses a certificate signed by an unknown authority. (4) - This connection uses a certificate signed by an unknown authority, but the authority certificate fingerprint matches the fingerprint from the last time you connected to this site. (5) - This connection uses a certificate signed by an authority in the browser's trust store. Browsers should only block a page with a warning if the fingerprint does not match from a previous session. Otherwise, the page should simply be displayed with the corresponding lock code in the address bar. Users should be educated that these levels indicate the eavesdropping protection of the connection, with an easy-for-normal-people-to- understand analogy, of a guy in a coffee shop. ie. "This security level protects you from eavesdropping by another customer in the coffee shop, but does not stop the coffee shop owner from eavesdropping using the coffee shop's WiFi router". A new type of authentication should be added to replace any certificate use besides "Domain Verification". For example, determining that a business exists and is legitimate. Business authentication, as a separate mechanism would probably use third party certificates of some kind, but would be a separate channel from encryption. In general, the biggest problem is browsers blocking sites, and not educating users. This is something that could be worked on now, although the other thing I had in mind is very different and warrants its own post.
