On Tue, Aug 13, 2024 at 1:25 PM Nick Lockheart <lists@xxxxxxxxxxxxxx> wrote:
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.
Yup. I am a big fan of SSH trust management. Except that it doesn't really flow as well as it could because I have trust on first use separate for each client machine.
The Mesh is built around append only logs authenticated by Merkle Trees, these are used to build catalogs (sets of items) and spools (lists of messages, events, etc.) and these are synchronized between all the devices a user connects to their personal Mesh. So if Alice adds Bob to her Contacts catalog on her phone, she can use that from every device. Contact assertions update automatically as well so if Bob adds Signal to his contact, Alice can immediately contact him on signal and could even achieve end-to-end trust for Signal communications if Signal were to allow that.
Same could be applied to SSH server keys so that your SSH context is automatically synchronized across everything.
I have some code here but I really need collaborators on this because I can see a way to do things which is not necessarily the best way. I can read SSH specs, sure. But I can't see deployment in the field like that. For example, SSH has client side and server side certificates. But Github only supports the client side certificates for paid accounts. I can easily work around but if github saw the value, they might make the adjustment at their end.
Just imagine using this in an open source collaboration, All you need to do is one click add a new member to the project and they instantly get their GIT signing key registered, authorization to push commits to the server and their developer code signing keys registered so other developers can pull their builds and run them in a default deny security posture where only signed code is allowed to run.
> 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.
+1
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.
I have championed that for years and the team at Google have taken the Web in the exact opposite direction.
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.
I am not a fan of either usability testing or user education. As with formal methods, the problem with usability testing is they only answer the questions you ask and those are rarely the right questions. And user education tends to be an excuse for dumping the architectural flaws the engineers are responsible for onto the user.
Take the oft given advice to be cautious when clicking on a link. How the heck is a user supposed to know? I certainly don't know how to tell the difference between a safe and unsafe link. And if I can't tell, well blaming your employee for one click destroying the corporation is stupid, the fault was that one click could have that impact.
We can't trust corporations who put dangerously short cables on appliances so they minimize their liability to have the best interests of Web users in mind. My social media feed is filled with malicious content daily because that is the most profitable for the content providers. Preventing ISPs hijacking Web requests to inject their own advertising was a completely understandable security concern for both Google and the users of their browser. But in their myopic pursuit of that particular private interest they destroyed the ability of users to know if they are dealing with a legitimate business or not.
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.
That is CABForum Extended Validation Criteria, the system Google has effectively dismantled.
