RE: extensions, continued.. (was: 05/24/2016 WebAuthn Summary

Hi,

Picking and choosing comments from the below emails.

> Now, how would the authenticator know about the user's preference?

Because the user configured it that way. Not all authenticators have one 1 button, especially not the ones in FIDO 2.0.

> So when you say that you expect the authenticator to respect your
> wishes, and we have an authenticator that *wants to* respect those
> wishes (and lets agree that we only want to support those kinds of
> authenticators),..

But those are not the only authenticators we (as authenticator vendors) are competing against.

What’s more, these are not the authenticators these measures are targeted against. Those authenticators would correctly process any extension and don’t need their extensions filtered.

> ..what other mechanism do we have to do that, other than
> the RP signaling the extension, the client/platform *understanding* the
> extension, and then - depending on the user setting - asking or not
> asking the authenticator to including the corresponding data?

The client doesn’t. But why do you set the client so central?  There is no reason the authenticator can’t be required to provide these configuration options if they want to support a location feature.

> I'm not talking about "bad" authenticators here. Bad authenticators will be able to subvert user privacy and security no matter > what we do. (I think other people made this point on another thread.) For that it's important to have legal/reputational
> recourses (in addition to technical solutions), and as Rolf points out, users are always free to switch to another
> platform/authenticator. So I'm not discounting those recourses.

I think you are misunderstanding the legal/reputational recourse. I am not a lawyer so far from an expert, but as far as I understand it, if a vendor is not a member and not certified, there is nothing you can do to them, whatever they chose to do to those nice APIs we’ve designed. In my understanding, FIDO Alliance has legal/reputational recourse against FIDO members with (or without?) certified devices, nobody else.

In my opinion, the legal recourse is meant for the certified FIDO members and the technical means against the “bad” authenticators.

The current measures that are implemented (the filtering of extensions) does not protect against “bad” authenticators and adds nothing to the protocol that the legal/reputational recourse not already provides.

> What I'm saying here is that we need some technical solution for clients and authenticators who *want* to protect user privacy.

If the authenticator and clients want to protect privacy, you do not need technical means to stop them when they want to do things you do not understand (what the current mechanism is), you need technical means to help them do it correctly.

This is something that bothers me about the current discussion. All arguments come from a platform point of view that both distrusts the authenticator and the relying party but implicitly assumes the platform is trustworthy. Which is strange because in our protocol design, the client isn’t actually a party in setting up the cryptographic trust.

I’ll add another argument: why should the client be able to read everything that passes between the authenticator and the relying party? This is just as much a privacy concern as location data. (Example? Message extension: “Are you sure you wish to register for sex-change surgery?”).

What should they do? How is an authenticator that's implemented in TrustZone, has no UI, and no way to communicate with the user agent other than through the webauthn APIs supposed to do the right thing? And how is a user agent that *wants to* protect user privacy (let's say, by obtaining user consent before disclosing the user's location) supposed to achieve that assuming that the authenticators want the same thing?

Nothing stops us from defining an extension containing the user preferences that can be added by the client. We can even force authenticators to honor them through the spec (make supporting it mandatory when present and applicable). It will even be passed on to the RP in the reply so it also knows why extensions were not honored. It certainly is a much more robust design that just letting clients remove things.

How does, for example, an RP know who dropped an extension? What if this extension add security in some way and a MITM removed it?

As a minor correction, the authenticator does not communicate with the client through the webauthn APIs but through the transport. We have a lot more freedom there.


Best regards,

                Johan

From: Dirk Balfanz [mailto:balfanz@google.com]
Sent: Thursday, June 09, 2016 2:04 AM
To: Hodges, Jeff <jeff.hodges@paypal.com>
Cc: public-webauthn@w3.org
Subject: Re: extensions, continued.. (was: 05/24/2016 WebAuthn Summary

On Wed, Jun 8, 2016 at 9:56 AM Hodges, Jeff <jeff.hodges@paypal.com<mailto:jeff.hodges@paypal.com>> wrote:
inline below..

> On Tue, Jun 7, 2016, 9:34 AM Rolf Lindemann <rlindemann@noknok.com<mailto:rlindemann@noknok.com>>
>wrote:
>> I agree, FIDO wants and (IMHO) should be privacy preserving.  And I
>> think we all agree on that.
>>
>> So the Œwhat¹ (IMHO) is undisputed.
>>
>> So we need to discuss the Œhow¹.
>>
>>> Because clients must be able to drop extensions they don't
>>> understand, all extensions must be requested by the RP.
>>
>> I don¹t think clients have to.
>>
>> What is the threat model here?  A user agent (or client) CANNOT
>> repair a broken platform.  In other words: If the underlying platform
>> violates user¹s privacy (e.g. by directly sending GPS location to
>> some server), the user agent cannot protect against that.
>>
>> The user agent (IMHO) can and should protect against Apps/JavaScripts
>> that try to violate user¹s privacy.
>>
>> Similar to a user needing to trust the user agent, the user (to at
>> least the same extent) needs to trust the underlying platform ­ or
>> use a different one.
>
> Agreed.
>
>
>> The user agent/client should be able to drop requests from the RP for
>> privacy violating extensions (according to the user¹s preferences).
>> So if the user configures the platform to not expose the location,
>> then I would also expect the authenticator to respect that setting.
>
> Exactly!
>
> Now, how would the authenticator know about the user's preference?
> It's not like the authenticator can turn around and ask the user. Also,
> we don't have CTAP messages that would allow the platform to tell the
> authenticator about the user preferences. The only mechanism we *do*
> have is for the platform (or user agent, or client, or whatever you want
> to call it) to help the authenticator out here and not forward the
> location extension argument if the user doesn't want the location
> exposed, and do forward it if the user is ok with the location exposure.
> That's the mechanism that we have to signal to the authenticator the
> user's intention.
>
> So when you say that you expect the authenticator to respect your
> wishes, and we have an authenticator that *wants to* respect those
> wishes (and lets agree that we only want to support those kinds of
> authenticators),..
>
> ..what other mechanism do we have to do that, other than
> the RP signaling the extension, the client/platform *understanding* the
> extension, and then - depending on the user setting - asking or not
> asking the authenticator to including the corresponding data?

This line of reasoning is relying completely on a technology-based
solution and ignores leveraging the reputational/legal recourse, as well
as certification testing, as described here..

I'm not talking about "bad" authenticators here. Bad authenticators will be able to subvert user privacy and security no matter what we do. (I think other people made this point on another thread.) For that it's important to have legal/reputational recourses (in addition to technical solutions), and as Rolf points out, users are always free to switch to another platform/authenticator. So I'm not discounting those recourses.

What I'm saying here is that we need some technical solution for clients and authenticators who *want* to protect user privacy. What should they do? How is an authenticator that's implemented in TrustZone, has no UI, and no way to communicate with the user agent other than through the webauthn APIs supposed to do the right thing? And how is a user agent that *wants to* protect user privacy (let's say, by obtaining user consent before disclosing the user's location) supposed to achieve that assuming that the authenticators want the same thing?


[1] wrt client filtering of extensions
    https://lists.w3.org/Archives/Public/public-webauthn/2016May/0306.html


The UVI extension is an extant, real example of an originally proprietary
authnr-produced extension (impl'd by a UAF authnr sdk & server vendor)
that adds data to the authenticatorData, and in original fielded practice
is passed through to the RP in authn assertions, and if the RP's backend
understands it, great, and if it doesn't the data is simply ignored.  RPs
do not have to update their front-end code to take advantage of it, nor do
they have to wait for the platform stack (which in the webauthn api case
includes the UA) to add support for it.

If an authnr vendor is caught abusing this capability, eg by certification
testing, there is reputational/legal recourse.

This line of reasoning is relying completely on reputation/legal recourse and ignores technical solutions. :-) We don't sue developers who trample on other apps' memory space - we built virtual memory instead. We don't try and stay away from websites with a bad reputation for sniffing passwords - we built the some-origin policy instead. When there are compelling use cases, we allow for them (shared memory APIs, CORS, etc.), but we do it carefully and without jeopardizing security/privacy. Let's do the same thing here.

Dirk.


I agree with Johan's analysis of added friction to the ecosystem..

[2] https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0065.html


..which is congruent with [1].


> Rolf continued..
>> And this is my recollection of where we ended the discussion in the
>> last W3C call, i.e. allowing authenticators to add extensions (in the
>> response)

agreed, that was also my understanding.


>> and allowing the user agent/client to drop extensions in
>> the request in order to reflect the user¹s preferences.
>>
>> I still trust the Authenticator vendors to only add privacy
>> preserving extensions which are added by default (similar to me
>> trusting the platform vendors to not violating my privacy in the
>> platform itself).

agreed, and here the reputational/legal recourse + certification provides
support for your trust.


HTH,

=JeffH