lexman0

This is my thinking.

>> Not a hash of the contents, just the sub/external domains' key-ids. Yes, the main page would have to change if you updated the keys. Doesn't seem too onerous to me.

Then that means each external domain has to tell all its linkers that its key will change whenever it does. Assuming it even has such a list. What if a party doesn't respond? I understand it would be said parties problem, but it sure does make re-keying difficult.

> Should you ever really trust kiosk machines? They could easily be setup with MITM eavesdropping software.

I should have the choice. This doesn't even give me that.

> Presumably there could be some sort of <meta> header that listed the public key fingerprint/IDs of any subdomains that the page was going to pull in. This would make the UX better.

This would make the UX barely passable. If any of these domains change the content at all so the hash changes, how does it get updated?

> AFAIK, revocation isn't very good even with the current CA infrastructure[1][2].

I completely agree with you, so lets not make it any worse.

I completely disagree with this. Public key pinning has some well known problems that make it very dangerous to implement at scale [1].

There are some very large problems that this introduces and does not solve:

- How do kiosk machines now work? How can I trust any website when every use is first use?

- What about https domains for images and scripts? Is the user supposed to trust each domain separately?

- Assuming trusting a domain trusts all its other domains mentioned in its content-security-policy, how is this trust revoked for misuse?

- Is the author suggesting that we retain all users of browsers everywhere? I believe that to be a herculean task.

Certificates have their problems, but this is not a solution. I will not propose one here, because it is an extremely complicated problem that needs many separate parties working together to solve.

[1] https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-ke...

While HPKP looks good, I really wouldn't implement it. Too dangerous for big sites in it's current form.

Ivan puts it better than me: https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-ke...

Generally the cliche is about not implementing your own cryptographic algorithms. As long as they only implement existing algorithms and don't generate new ones, I don't think this applies.

"Although Mozilla’s sanctions are too severe..."

These guys must be joking. Trust has been lost, the roots should be permanently revoked.

If anything, I think Mozilla's actions are not severe enough. How likely is it that Mozilla doesn't know the full story? There may be additional violations that have been missed.

Oh no! Now where will I get my smug sense of satisfaction from?

True enough.

But those who steal your account information and use it to pose as you don't follow the rules and regulations.

There are a lot of keyboard warriors in this thread. This guy puts forward a rational argument for big business.

Unless you have extensive experience in this area, perhaps you shouldn't be so quick to judge "oh they are just spying on their users".

The simple answer to this question is that if a way is not given for businesses to decrypt their own traffic that they generated and encrypted, they simply won't encrypt it.

Take this example: A regulation says that all incoming traffic into a banking sector company must be scanned for potential vulnerabilities and exploits, and allows for "compensating controls". If the incoming traffic is unable to be decrypted at TLS1.3, it will simply be decrypted at the boarder of the business and routed internally unencrypted. This would be worse than copying the TLS1.2 traffic for out-of-band scanning.

I'm not saying that this guy wasn't a little late by the party, but failing to recognise that big businesses have regulations you don't understand or even care about is a huge mistake that will make us all more insecure. After all, who doesn't have a bank account?