Cluttering the TPM and potential denial of service ?

[HoLyVieR]

From what I understand of this proposal, it seems like a public key would be created and stored in the TPM of the device for every unique domain the API is used in. One of the main issue that I could see with this is that a malicious website (ex.: myevilwebsite.com) can have a page that opens iframes to a huge amount of his own subdomain (ex.: a.myevilwebsite.com, b.myevilwebsite.com, ... zzzzzz.myevilwebsite.com) and have all those subdomains request to use this features. An arbitrary large amount of TPM key would be created on the device. Considering TPM don't have infinite storage, could this feature be abused to clutter the TPM storage of a device visiting the malicious website ?

[kmonsen]

There are two things to consider here, TPM storage and TPM compute latency as it is serial.

For TPM storage on Windows it is virtually unlimited, but we will probably put some limits in place to make sure there is no abuse.

For TPM latency this is a bit more tricky as merely ~100 session in use at the same time will fully utilize the TPM. We already have a queue system in place for this and will prioritize active tabs but it is an issue to think about.

Note if we support VBS keys for Windows: https://techcommunity.microsoft.com/t5/windows-it-pro-blog/advancing-key-protection-in-windows-using-vbs/ba-p/4050988 the latency concerns are mostly gone but there are some storage limits.

Thank you for your comment, this is something we have been thinking about a lot and it is not clear what the solutions will look like but we do think it is something that can be controlled. If you have any feedback on what you think solutions should look like we would be grateful for suggestions.

[HoLyVieR]

One of the thing that I have in mind is having some restrictions on how many subdomain (per top-level domain) can have a TPM entry. A subdomain is basically free to create while a top-level domain typically comes with some small fee (5$-15$) to create. A limit of ~100-200 entries (or something of this scale) for subdomains per top-level domain could be a good starting point as it's unlikely that a top-level domain needs that much in practice and it would limit the damage a top-level domain could create alone. With that kind of restrictions the cost of doing this type of attack would go from 5$-15$ to a number in the thousand of dollars if not more (no longer trivial).

[kmonsen]

Thank you for your suggestion. This would work for us, we will ask others interested in the API as it is on the path to standard if this as an acceptable solution.

[mattjm]

Are architects from Okta/Auth0 involved in discussions around this in other mediums? I feel like auth0.com and okta.com are some of the most likely domains where someone would hit this limit. But only in theory...5 years at Auth0/Okta and I am counting 52 entries in my 1password referencing auth0.com--and I think all of those are not a match on the domain. And folks using our service can (and usually do) set up their own domain.

I can't speak for Okta on this but I think I can get one of our architects to comment if they're not involved already.

[kmonsen]

Yes, I was thinking of Okta when saying I would talk to others first as I remember Okta relies on subdomains.

[mattjm]

So just to be clear you have lines of communication already you will use to raise this?

[kmonsen]

Yes

[TaaviE]

Given the really high impact if these APIs are abused I don't think this should be done without user consent. Just like Passkeys (and some hardware tokens having limited storage for those).

[kmonsen]

Given the really high impact if these APIs are abused I don't think this should be done without user consent. Just like Passkeys (and some hardware tokens having limited storage for those).

Can you be more concrete on what your specific concern is? To be clear Windows TPM keys are not stored in the TPM so there is unlimited storage (limited by disk storage).

[TaaviE]

@kmonsen

Can you be more concrete on what your specific concern is? To be clear Windows TPM keys are not stored in the TPM so there is unlimited storage (limited by disk storage).

Can that assumption be made for all platforms?

As you've described earlier, the amount of concurrent sessions is also limited, any website being able to consume a limited resource just seems ripe for abuse.

[arnar]

In general, an implementation of DBSC can definitely itself open new avenues for abuse, e.g. this kind of DoS attack.

I think as is, it will be on implementors to defend against these, e.g. with rate-limiting and heuristics for shared domains as described above. But if there's anything we can add to the protocol or API, and the complexity-vs-benefit tradeoff is positive, we should discuss concrete suggestions on that.

At the end of the day, the evaluation has to include whether that new form of abuse (e.g. DoSing bindings for other websites) is more or less valuable than the abuse enabled by cookie-theft.

[HoLyVieR]

@arnar I'm not sure it's entirely wise to left abuse mitigation to implementor. I believe this could clash with the project objective of not introducing "additional surface for user tracking". Implementors mitigation are likely fingerprintable and a non-uniform implementation could make it possible to distinguish which device and browser is being used by testing the limit of the API.

[Avamander]

I think as is, it will be on implementors to defend against these, e.g. with rate-limiting and heuristics for shared domains as described above.

This approach was taken with Webauthn, unfortunately it resulted in a lot of inconvenience. Webkit's implementation was the only one that required user action, breaking most sites (a few bigger ones got "nicely" allowlisted) that had Webauthn support.

I understand the wish to avoid dictating exact implementions, but it should be possible to assume some aspects about anti-abuse (be it user consent or rate limits).