W3C home > Mailing lists > Public > public-webauthn@w3.org > June 2016

Extension whitelisting, reprise

From: Johan Verrept <Johan.Verrept@vasco.com>
Date: Mon, 6 Jun 2016 11:17:21 +0000
To: "public-webauthn@w3.org" <public-webauthn@w3.org>
Message-ID: <ea8122d5f329463693c25712315ff994@srv-colo1-exch.vasco.com>
Hello gentlemen,

I would like to take a step back on the extensions and discuss the chosen mechanism: whitelisting. I have posted about this on the fido-2-twg but all discussion seems to happen here.

I am convinced that, with the current proposals,:

-          Whitelisting will never work as intended.

-          Whitelisting will block innovation.

-          Whitelisting will only affect certified vendors/products

I understand that clients want to help protect the users. I have no objections to this, on the contrary, I just do not believe whitelisting of extensions is going to help them do this. We, as the FIDO Alliance, are just loading the dice against ourselves and not achieving anything.

I believe we would end up with a better FIDO 2.0 ecosystem if we just drop whitelisting, limit ourselves to controlling the certified vendors (registration of supported extensions?) and warn the user when they are not using a certified authenticator.

Whitelisting will never work as intended

To make the whitelisting work, you would have to implement strict extension parameter validation and even then,  you cannot close down all the side channels. For example, the "message" extension in the spec, I could use specific sentences, phrases, words, typos or punctuation to pass information or trigger functionality in the authenticator. Even if you lock down every possible parameter of every extension to a strict list of possible values, an attacker can just use a combination of these values to convey information.
If you do not use parameter validation or intend to stop the information flow, why bother with whitelisting in the first place?

Whitelisting will block innovation

Whitelisting with any parameter validation will require code from the clients. This means any extension is subject to the release cycles, roadmaps, priorities and politics of the clients/platforms. I do not believe that if a new extension is proposed and approved by FIDO, it will get implemented and widely supported within a reasonable timeframe, if at all. Client vendors just do not have an incentive. In the best case, if you get everyone on board, I estimate this at 1-2 years before a proposed extension is out in the field. (BLE support in U2F is an excellent example of this).

Whitelisting will only affect certified vendors/products

This is the worst part, I think. FIDO just doesn't have a stick to hit those vendors that do not certify their products or use the FIDO logos. You are severely limiting the FIDO vendors in what they can do while any other vendor can just (ab)use the FIDO client infrastructure to do whatever they want. You cannot stop them in any way by adding more FIDO rules (even blacklisting authenticators in clients only works because of FIDO rules/specifications).

Best regards,

                Johan
Received on Monday, 6 June 2016 12:57:51 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:21 UTC