Re: [webauthn] Adding a choice for RP to express preferences for attestation types

The Infineon bug is worth thinking about in order to think about why RPs might want to look at attestation data retrospectively.

The overall goals, at least from my point of view, are to solve phishing, password reuse, and social engineering. If some vulnerability is found that compromises those goals, then RPs would want to address that.

#### Generation or wrapping problems

The Infineon bug, for one, is a case where attestation data is uninteresting. It's possible to identify a weak key from the public key and looking at attestation information would just introduce an extra step and false positive / negative risks.

The Debian weak-keys issue was the same.

In fact, if there's a problem of the type where it's feasible to work out a private key from the public key or key handle, RPs can always just try the attack against their key database, which gives more reliable results than asking every manufacturer for a breakdown of the impact on their devices. (Which may not be neatly segmented into different attestation certificates anyway.)

We can think about the case where the attack is cheap enough to be problematic, but not cheap enough to be attempted en-mass, and without any cheap distinguishing function. However, for ECC keys, I'm not sure that's actually possible. I think any such issues would have a sub-linear cost for checking _n_ keys. It's an interesting thought exercise if anyone can come up with one.

Perhaps there could be a problem where doing a single instance is still considered infeasible for the RP, but feasible for the attacker, but that seems to be the only niche left.

#### Local attacks

One can also think about vulnerabilities that require direct USB access, i.e. malware running on a machine with a token connected is able to extract keys. It seems plausible that some tokens could have such bugs.

But, while not ideal, it doesn't violate any of the initial goals. Users with malware installed already suffer from a wide range of issues as the malware can try to move horizontally and compromise the browser.

#### Remediation

While retrospective analysis of attestation information seems to be of minor utility, it's also unclear that RPs are the best place for dealing with the issue. Some RPs will care and, for those, it appears very likely that attestation information wouldn't be very useful in their response. But if we believe that some token is so hopeless that users need to retire and replace it, would we rely on users happening to interact with such an RP? It seems that we would probably need to update clients to alert users in order to alert a reasonable fraction of affected users.

If there is an argument that I've not thought of for why attestation would be especially useful in responses, it's not difficult to imagine an attestation proxy inserting data in a certificate that can be used for retrospective unblinding, should the proxy operator accept that was necessary. (Although perhaps that falls under the topic of “revocation”, which I agree has not worked well in the X.509 PKI, although I think the setting is quite different here.)

### On the other hand

There are more reasons for being cautious with attestation than just privacy: although a privacy scare could significantly hamper this effort overall.

Firstly, if many RPs all come up with their own policies for which tokens to accept and which to reject, we risk fragmenting the user experience. If it becomes common-place to need multiple tokens in order to reasonable coverage of RPs, users will have to start remembering which token works with which site. The reputation of U2F/webauthn tokens in general will suffer from the poor user experience.

Secondly, there is risk that some early token manufacturers will be positioned to extract rents by virtue of the distribution of their attestation roots. New entrants could be frustrated by the infeasibility of getting tens of thousands of RPs to trust their new devices. We have seen that happen in the WebPKI.

The FIDO MDS is hoped to solve a lot of the above issues, and perhaps it will. Although last time I checked it was significantly incomplete. However, if we let the ecosystem develop with direct attestation then fixing those issues later will be exceptionally difficult. In short: this has the hallmarks of an irreversible decision, which, for an ecosystem as an important as we all hope this one will be, should provoke significant caution.

Thus, while there are certainly cases around enterprise uses where direct attestation is sensible, it seems wise to move more slowly in the general case.

-- 
GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/636#issuecomment-337111038 using your GitHub account

Received on Tuesday, 17 October 2017 03:58:52 UTC