Hmm. I think end-to-end needs to remain end-to-end, and you don't need to trust a plethora of third parties if everyone is using the same library/platform for encryption. Middle parties don't need to know anything about the encryption.
The source for that library will be extremely well vetted. Maybe the most vetted code ever written.
There are practicalities, such as how improved encryption gets added to the protocol, and how clients from previous versions negotiate the best supported encryption between them.
Also, affordances for encrypted delayed transmission, i.e. storage in the middle. For instance, email providers would need to store encrypted messages until your local reader downloads them (either to read or store locally).
In some cases such as backups, and syncing between your own clients, end-to-end would really just mean your end. As only you would ever decrypt anything.
Either way, zero need for any third party to be involved in the encryption, other than the source & binary provider.Go with a highly respected/vetted version, or even a standards committee's reference implementation officially vetted by many entities, and a mechanism for anyone to vet and report.
There is some thought needed for the design, as with any platform. And perfection might never be achieved - but things are much less perfect today.
The return on that careful work would be an insane drop in the number of disparate implementations needed, and a much safer internet without all the cracks in and between disparate implementation.
The ISP would still be untrusted. They're just running a database/discovery service for your public key.
Now you might say, what stops them announcing the wrong public key to the world, and then decrypting/re-encrypting a connection when it flows inbound to that IP across its wires. And the answer is the same as with TLS/SSL: not much, so you have to do lots of double checking and pinning.
Recall that nothing in today's internet really rigorously stops an ISP obtaining a certificate for a website it hosts, or even one that it doesn't! A CA like LetsEncrypt will automatically probe an IP from several vantage points as part of validating a domain->IP mapping but that process can be triggered at any point, and the vantage points can be easily discovered. So an ISP that can 'catch' all the vantage points, can just redirect IP traffic from the CA to its own server to obtain a cert, and then MITM traffic heading towards a website. It's the same problem when doing it at the IP level.
However, there is still a lot of value because you can get public keys in a variety of ways. For instance you could try to connect to yourself back via Tor, or a variety of other services, to verify that your public key the rest of the internet sees is what you think it is.
I disagree, incentives would be very different imo.
> Now you might say, what stops them announcing the wrong public key to the world, and then decrypting/re-encrypting a connection when it flows inbound to that IP across its wires. And the answer is the same as with TLS/SSL: not much, so you have to do lots of double checking and pinning.
in WebPKI:
- CA's have struct rules (CAB and individual browser vendors) and have to go through audits to verify they follow them (how much an audit is worth is debatable)
- certificate transparency ensures that CA's can't misbehave without being detected, which if they do, they get kicked out as a CA.
If an isp misbehaves in this scenario, how do we punish them? Can we kick them out of the internet? Seems unlikely. If a CA refues to do something, we can kick them out.
> and pinning
I personally think pinning is generally a bad solution to pki problems, but for the sake of argument: how do you do pinning (or even something simpler like TOFU) with only a transient identifier like a dynamic IP address? What do you pin to?
Its even worse if you still want to support NAT.
> A CA like LetsEncrypt will automatically probe an IP from several vantage points as part of validating a domain->IP mapping but that process can be triggered at any point, and the vantage points can be easily discovered. So an ISP that can 'catch' all the vantage points, can just redirect IP traffic from the CA to its own server to obtain a cert, and then MITM traffic heading towards a website. It's the same problem when doing it at the IP level.
Which can be immediately noticeable via certificate transparency. More to the point, there is no single attacker who is on path for all of lets encrypt's vantage points (and you don't have a relationship with any of lets encrypt's isps so they are less likely to care about you), which wouldn't be true for this new scheme. I guess you could argue that the web host in the webpki case (when not using dns validation) is the most likely point of attack, but they could just attack directly since they own the hardware.
> However, there is still a lot of value because you can get public keys in a variety of ways. For instance you could try to connect to yourself back via Tor, or a variety of other services, to verify that your public key the rest of the internet sees is what you think it is.
Its easy to come by lists of public proxies. Tor itself publishes a list of all ips participating in the tor network.
Ultimately the biggest problem is enforcement incentives. Much of the security of web pki relies on being able to detect and punish misbehaving CA's (of which there are only a small number of). I don't see a politically viable way of doing that for ISPs.
WebPKI doesn't really solve these problems.
CA Audits are mostly about ensuring they're following the rules. However, the rules cannot stop an ISP or hosting provider just issuing themselves a cert and a fully audit compliant CA is not expected to stop this.
Cert transparency is mostly unused. For it to work people have to proactively search the logs to find certs they didn't issue, but in reality nobody does this outside of maybe big tech firms. Moreover, in the ISP/colo interception case, the CA wouldn't be revoked because they wouldn't have done anything wrong.
Re: pinning. You can't pin if your IP isn't stable. However you can if you're a server. Then you don't need the fragile link of DNS in the loop at all. For instance, mobile apps can just have a cached public key (of course you can do that today, but we're talking about a system that is more deeply integrated with the internet).
"there is no single attacker who is on path for all of lets encrypt's vantage points"
No? AWS isn't on path for all the websites they host?
Even in the case where the hardware isn't owned, any site that has one internet uplink (i.e. most of them) can be targeted in this way.