Re: Proposal: Chrome privacy CA

Hi  Adam,

Welcome into this thread.

> On Tue, Nov 7, 2017 at 2:03 AM, Denis Pinkas <denis.w3c@free.fr 
> <mailto:denis.w3c@free.fr>> wrote:
>
>     With the Privacy CA infrastructure, Google would be introducing a
>     potential /spying component/in the model. The Privacy CA
>     infrastructure would allow
>     to gather information likethe identity of the token vendors and
>     the rate of use of such hardware tokens. That information could
>     then be used to perform
>     a market survey for the benefits of Google and/or be sold to some
>     unspecified parties. Google would be the only one able to perform
>     such a market survey.
>
>
> If we could have viably implemented this as a non-interactive, 
> zero-knowledge proof in the browser, we would have done so, but I 
> could not make those numbers even close to viable. It would also add a 
> substantial burden to RPs trying to validate tokens.
>
> Thus the amount of information provided to the Privacy CA is the 
> minimum. If the aggregate information about token popularity is 
> considered sensitive then the model of direct attestation by default 
> would have given it to essentially all non-trivial sites (and probably 
> still will, since Chrome is not the only browser). Presumably that 
> wasn't considered a problem previously.

By default, self-attestations should be used. So nothing at all would be 
given away. This is what comes out when you apply "Privacy by Design" 
and "Privacy by Default" rules.

Giving no information at all to the Privacy CA would indeed be the 
minimum amount of information. Token popularity and countries of use of 
these tokens are other information
that Google would be able to gather and this should be avoided.
>
>     You said: "/many RPs will ask for attestation just because they
>     can/". No, this is not as simple. In order to verify a certificate
>     attestation,
>     the RP needs to get at least one root key per hardware token
>     vendor and to make sure that the root keys are the right ones.
>     Presently, there is no specification that tells them where from
>     they can (securely) get these root keys.
>
>
> I believe the MDS is intended to solve this problem. However, it is 
> currently significantly incomplete and so we believe that your 
> expectation of the problems is essentially accurate in the medium term.
>
> Our worry is then that RPs will use ad-hoc and varying processes for 
> verifying tokens, which will not be updated over time. That will lead 
> to a poor user experience as different keys will function with 
> different sites. Attestation will also become a significant barrier to 
> entry for future token vendors who will need a multitude of sites to 
> update their attestation roots to accept their tokens.
>
> While this might get sorted out over the course of years, it takes far 
> less time than that for a technology to acquire a poor reputation. 
> Consumers have a compelling interest in being able to select from a 
> number of vendors and to be reasonably sure that a purchased token 
> will function across the vast majority of sites.
>
>     The easiest for RPs will be to use self-attestations *and to
>     verify these self-attestations* because with the current protocol
>     this is currently
>     the only way to get a proof of possession (PoP) of the private key
>     at registration time.
>
>     You also said: "/identify batches of tokens if revocation is ever
>     needed/". In case of revocation, the first need is NOT to revoke a
>     batch of tokens
>     but to *revoke an individual token*. The Privacy CA model will be
>     of no help to achieve such an objective.
>
>
> Attestation certificates are required to be deployed in batches of at 
> least 100K already, so identification and revocation of a specific 
> token is already a non-goal of FIDO.

Revocation of a specific token is currently impossible in FIDO since all 
RPs are considered to be equal. If you remove this equality, then a new 
bunch of possibilities emerges.
So saying that is is a "non-goal of FIDO" may not be an appropriate 
statement. From a functional point of view, it would be nice to be able 
to revoke a specific token
and this is possible as soon as you introduce a distinction between :

  * RPs that need to know whether an authenticator conforms to some
    security and functional requirements,
    and in this case the use of an attestation certificate will be required.

  * RPs that don't need to know whether an authenticator conforms to
    some security and functional requirements,
    and in this case the use of an self-signed certificate will be required.

This means that a given hardware token should be able either to generate 
a self-signed certificate or to use its attestation certificate upon the 
request from the client.

If you want to remain compatible with the current situation, you always 
request the use of an attestation certificate, ... if some way or another
you know that the same certificate is being used for a batch of at least 
100K tokens. BTW, today there is no mean being defined to know whether 
the attestation certificate
applies to a single token or a batch of tokens.

Making the distinction between two kinds of RPs opens the door to new 
possibilities, in particular, the revocation of a specific token.

> That is a balance between the wider interests of common users (who do 
> not wish to have a tracking token) and the interests of closed, 
> enterprise deployments,
> who might like to be able to identify specific tokens, track them in 
> inventory systems etc.

The balance is simply not between two parties (common users and RPs) but 
between three parties :

  * common users,
  * RPs that need to know whether an authenticator conforms to some
    security and functional requirements, and
  * RPs that don't need to know whether an authenticator conforms to
    some security and functional requirements.

> Item #5 in our requests attempts to reconcile this a little 
> differently and envisions a signal to tokens that they are being used 
> in a context where individual attestation is appropriate, and might 
> thus return a different, unique attestation certificate.

By default, the use of an attestation certificate (whether unique or 
shared) would be inappropriate. By exception (i.e. upon request), it 
would be.

> In Chrome, that signal would be wired up to our enterprise policy to 
> allow administrators to enable direct attestation for enumerated RP IDs.

FIDO is intended to be usable on the Internet, I mean not only within an 
enterprise environment.
Within an enterprise environment the added value of FIDO will be "ease 
of use" and "security", it will not be "privacy".
Within an enterprise environment privacy is not the major concern, but 
on the Internet it is.

Denis

>
>
> Cheers
>
> AGL