dennisjackson / trust-negotiation-comments

2 stars 0 forks source link

Divergence and Fragmentation section assumes that root program requirements “trickle down” to other clients, rather than other clients “trickle up” to affect root program requirements #7

Open dadrian opened 4 months ago

dadrian commented 4 months ago

The Divergence and Fragmentation section makes a unilateral statement that browser policies “trickle down” to other types of clients, which are assumed to be less secure. While this can be true, it is equally true that the requirements of devices with weaker security policies hold back clients that wish to have stronger security policies, but cannot due to the availability tradeoff that servers who wish to support both the older clients with weaker security policies, and the newer clients with stronger security policies.

For example, if an out of support but still widely used TV set top box accesses the same server host as an up-to-date modern client, the modern client cannot change its security requirements in a way that would be incompatible with the TV set top box without forcing servers to choose between breaking the set top box and breaking the client.

It also assumes that trickling down to older clients is more important to the security of the web as a whole than making up to date clients more secure. This approach is backward to the usual security paradigm of focusing on up to date software being secure.

dennisjackson commented 4 months ago

Can you give an example where this has happened or where you expect this might happen?

nharper commented 4 months ago

SHA-1 deprecation comes to mind as an example of where this has happened. If root programs had a trust anchor negotiation mechanism when that deprecation was done, modern clients could have moved off of SHA-1 much more quickly. Instead, root programs had to wait until the breakage of old devices was small enough to be acceptable.

(I know that this same example is cited in the doc in arguing that trust anchor negotiation would result in the loss of this "trickle down" ratcheting effect. There's a wide distribution of clients participating in the Web PKI, ranging from modern auto-updating browsers at the head, to a long tail of embedded devices. When root program policies are held back by the long tail, that affects the security of all clients and servers in the ecosystem. Being held back by the long tail is exactly what happened in the SHA-1 deprecation case.)

dennisjackson commented 4 months ago

That's not quite right though. Root Programs had to wait until enough websites had moved off SHA-1 certificates to avoid bricking their own users. With certificates having 3 year lifespans and almost all of them manually issued, waiting for websites to get new certificates took the majority of the time. IIRC, we're talking about nearly all client devices having updates available and applied, but 25% of websites still using SHA-1 certs until the UX warnings started kicking in.

Trust Anchor negotiation doesn't change this wait (ACME and short lived certs do).