5 ms·

I think they're referring to attestation (https://fidoalliance.org/fido-technotes-the-truth-about-attestation/#:~:text=Making%20sure%20that%20attestation%20cert

• dane-pgp 4y ago
  The point being, the FIDO Alliance reserves the right to blacklist any device that an attacker manages to extract the secret keys from, which has the consequence that 99,999 other people have their devices bricked. Also, the Alliance could decide to blacklist a manufacturer just because they haven't implemented some new policy (like requiring a DNA scan of the user) so you better make sure that you buy a device from one of the "too big to fail" providers.
  • md_ 4y ago
    > The point being, the FIDO Alliance reserves the right to blacklist any device that an attacker manages to extract the secret keys from, which has the consequence that 99,999 other people have their devices bricked. 1. By what mechanism can they blacklist a device? A given relying party can choose to use or not use attestation and, if they choose to use it, which certificates to trust. But that's between you and the RP. Authentication doesn't "talk to" the FIDO Alliance--which is just a standards body and does not (AFAIK) even publish anything like a CRL for "bad" attestation keys, so I don't understand what you are talking about here. 2. The intention of the attestation, as I understand it, is to enable RPs to use attestation to limit authenticators to e.g. those that pass FIPS certification (or similar enterprisey requirements), not to ban a whole batch because one key is known to be compromised. That's crazy; can you point out where anyone other than you has ever proposed this? 3. DNA scan? What are you talking about? 4. This assertion you are making, while bizarre and wrong, is very different than the assertion the grandparent made ("Yubikeys intentionally have a very small number of devices signed with one CA key...so those devices do have a basically unique identifier"), which, while also wrong, is I think a genuine mistake and not a bad-faith argument.
    • dane-pgp 4y ago
      > A given relying party can choose to use or not use attestation and, if they choose to use it, which certificates to trust. True, and a website could decide to issue its own certificates rather than get one from a CA trusted by browsers, but in practice (and potentially one day by law) most sites will defer to the FIDO Alliance to determine which devices are "sufficiently secure". > the FIDO Alliance--which is just a standards body and does not (AFAIK) even publish anything like a CRL for "bad" attestation keys "The FIDO Alliance Metadata Service (MDS) is a centralized repository of the Metadata Statement that is used by the relying parties to validate authenticator attestation and prove the genuineness of the device model."[0] > That's crazy; can you point out where anyone other than you has ever proposed this? "If the private ECDAA attestation key sk of an authenticator has been leaked, it can be revoked by adding its value to a RogueList."[1] > DNA scan? What are you talking about? I picked a deliberately extreme example to make the point that there are requirements for these devices that users might not be happy with (but might not have any choice about, once the capability becomes ubiquitous). That specific example may never come to pass, but I don't think we should assume that allowing RPs to put arbitrary conditions on the hardware we use is a power that won't be abused. For added context: "FIDO will soon be launching a biometric certification program that ensures biometrics correctly verify users. Both certifications show up as metadata about the authenticator, providing more information to enable services to establish stronger trust in the authenticators.)"[2] > This assertion you are making, while bizarre and wrong ... a bad-faith argument. Maybe you should have assumed good faith. [0] https://fidoalliance.org/metadata/ https://fidoalliance.org/metadata/ [1] https://fidoalliance.org/specs/fido-uaf-v1.2-rd-20171128/fido-ecdaa-algorithm-v1.2-rd-20171128.html#revocation https://fidoalliance.org/specs/fido-uaf-v1.2-rd-20171128/fid... [2] https://fidoalliance.org/fido-technotes-the-truth-about-attestation/ https://fidoalliance.org/fido-technotes-the-truth-about-atte...
      • md_ 4y ago
        > True, and a website could decide to issue its own certificates rather than get one from a CA trusted by browsers… That’s quite different. In your example, if a website does so unilaterally, client user agents break. In the FIDO case, nobody else knows or cares which authenticators an RP trusts. More broadly, I don’t get this conspiracy theory. You’re worried…the FIDO alliance will abuse their very limited power to…what end? > If the private ECDAA attestation key sk of an authenticator has been leaked, it can be revoked by adding its value to a RogueList."[1] The attestation key, which is shared among all devices? That’s rather different from what you said. > That specific example may never come to pass, but I don't think we should assume that allowing RPs to put arbitrary conditions on the hardware we use is a power that won't be abused. RPs already have such power. Today they use it to do things like require password complexity policies. Again, RPs aren’t the FIDO alliance; they’re the actual website you’re logging into. Your repeated argument here is that websites should not be allowed to impose restrictions on how their users authenticate, which is hard to fathom. In a previous version of this argument, I remember you essentially arguing that banks and enterprises should not be able to restrict what types of authenticators their employees and customers use. I get it. You hate attestation. But “my employees must use a fips-certified key” (or “my customers must use a hardware key”) is reasonable and ultimately non-negotiable if you want people to use your protocol.