Webauthn: FIDO U2F Attestation Statement Format doesn't say what to do with Counter

[jcjones]

Similar to #506 ... when creating a new credential, the U2F wire protocol doesn't provide back a Counter value. We should define how UAs should behave in this case.

The options we've discussed before are:

1) Encode this as all zeroes, or some other sentinel value to indicate that it is unset.

2) After generating a new credential, UAs must immediately trigger a U2F Sign operation with that credential using bogus data to obtain the Counter. This will require an additional Test of User Presence before the Create Credential flow completes.

(Firefox is picking Option 1 w/ all zeroes for now, and we'll update as this resolves)

[agl]

(Could also be resolved by removing the signature count. See #453.)

[AngeloKai]

This could be related to https://github.com/w3c/webauthn/issues/125

[equalsJeffH]

having counter values is a given and are in fielded devices we need to support. we need to document RP counter usage in impl-cons. counter(s) is an anti-cloning measure. see also issue #125 which is calling for such explanation -- thx @AngeloKai

[agl]

I believe that the signature counter was a mistake because of its limited utility and privacy risks.

The FIDO spec hints that the signature counter may be used to identify duplicated keys, but provides no guidance about how they see that happening. If a token fails to write to flash and thus repeats a counter, should sites reject that token and require a reenrollment? How is the latter to be authenticated? It seems to me that the base-rate of false positives would completely swamp the _extremely_ rare true-positives and thus nobody would bother.

On the other hand, in order to only need a constant amount of storage, U2F tokens generally maintain a single, token-wide counter. Thus the counter is a privacy leak between sites and adds a requirement that tokens maintain state.

Current U2F devices emit this counter and that has to be taken into account, but in #453 I suggest repurposing it as a randomisation field. This gives tokens (that want to use it as such) a defense against side-channel attacks and would allow future tokens to fix this privacy leak.

[nadalin]

@rlin1 to write up algorithm for RPs to use counters

[rlin1]

see branch sign-counter-alg-507

[rlin1]

See PR #539 for further discussion and decisions.

[rlin1]

has been addressed by merging PR #539 IMHO

[nadalin]

@rlin1 Can we close this then with the reference to #539 ?