Re: Comments to WD-01

Hi Vijay,

Sorry for the delayed response. See some more comments below.

Thanks,

     Yaron


On 14/09/16 22:06, Vijay Bharadwaj wrote:
> [...]

> 4: "Support for deleting credentials is deliberately omitted" - 
> shouldn't we at least specify what the platform should enforce, e.g. 
> user verification? Otherwise any application may be able to downgrade 
> 2FA solutions back to baseline password-only security.
>
> I’m not sure I understand. From a security perspective, it is not 
> clear why deleting credentials should require user verification. Maybe 
> you would do so as a usability measure (to make sure the deletion is 
> not accidental) but that does not seem necessary to mandate. It’s also 
> not clear why deleting credentials would downgrade anything to 
> password-only security. The RP can still ask for 2FA, just a different 
> kind (e.g. automated phone call or SMS code).
>
These other 2FA methods, in particular SMS, are easier for a malicious 
app to spoof. Also, if 2FA is not mandatory, the user will choose to 
avoid it after the credential is deleted because it "doesn't work".

[...]
>
> 4.1: When obtaining a WebAuthentication interface, is there a way to 
> choose between multiple Authenticators if more than one is available?
>
> One does not “obtain a WebAuthentication interface”. This is written 
> in WebIDL like all W3C specs are, but web developers will only 
> interact with the Javascript binding of this. Think of the methods as 
> static, if that helps.
>
> Choosing between multiple authenticators is left to the client to 
> mediate, as described later in the spec. Having a website be able to 
> enumerate authenticators in range of your client creates possible 
> privacy leaks.
>

> [...]

> 4.1.1 step #9: calling multiple authenticators in parallel for the 
> same credential means that the user needs to "touch" each one. Is this 
> really what we want? At the very least, this is very confusing to the 
> user. Even more so in conjunction with the proposed 
> authenticatorCancel operations (step #10) which are bound to result in 
> race conditions between the authenticators.
>
>   * 4.1.2, end of section: "the user agent SHOULD show some UI to the
>     user to guide them in the process of selecting and authorizing an
>     authenticator" - this text conflicts with the requirement to send
>     the request to each of the authenticators in parallel.
>
> All potentially usable authenticators are invoked in parallel. This 
> will cause all of them to start blinking (or whatever they do to get 
> attention) but as soon as the user touches any one the others turn off 
> (due to the cancel you mention). In fact, the parallelism is what 
> makes it so the user only has to touch one. If we went through the 
> authenticators one by one, the user would have to touch a number of 
> them. Having the client help the user understand what’s going on does 
> not seem to contradict this.
>
In order for the client to "help the user understand what's going on" by 
displaying an intelligent message, it would have to list all relevant 
authenticators, which would conflict with the privacy issue you raised 
in your comment above. Or are you assuming that the client has UI that's 
independent of the web site, and not visible to it?
>
>   * 4.5: The excludeList allows an RP to tie different identities,
>     i.e. to check if Alice and Bob are both used as identities on the
>     same authenticator. This is because each of the
>     CredentialDescription structures can contain a different id value,
>     whereas if we only wanted to prevent multiple credentials for the
>     same account, we would simply use the id value of the Account
>     structure. Is this an attack we are willing to live with? Why not
>     require (or allow) user consent for this step, e.g. "RP X wants to
>     see other identities you have with it, do you allow that?"
>
> One issue is that there are authenticators which have no local 
> storage, but encode the entire credential and all its metadata into 
> the credential ID. So for these authenticators, a credential ID is 
> required. However, you make a good point that the authenticator could 
> ignore any excludeList entries that are not for the same account ID. 
> Would you please open a new issue?
>
#204
>
> [...]

> 4.8 (WebAuthnExtensions): the last paragraph refers to 5.2 (signature 
> format) and should probably link elsewhere.
>
> Please open a new issue.
>
#205
>
> [...]

>   * 5.1.2: "The identifier of the credential used to generate the
>     signature" is returned to the client, but AFAICT it is not
>     actually signed. I'm not sure there's a direct vulnerability
>     because of that, but I think including the ID in the signed
>     material is a best practice.
>
> Good point. I do not see an attack either, or at least no attack that 
> does not also require the signature scheme to be broken in the first 
> place. Interesting discussion point though.
>
#206
>
>   * 5.2.1: The explanation why the hash of the RP ID is not agile is
>     correct for roaming authenticators with the *same* RP ID. But
>     there's no reason why a new RP should not use SHA-512 with all of
>     its authenticators, so crypto agility still makes sense in this
>     context. I suggest to prefix the hash with a one byte version number.
>
> But how would the client know which version to use? The authenticator 
> is expecting the same version it saw when creating the credential, and 
> the client does not know what this version was.
>
[...]
>
>   * 7.3: "Clients SHOULD ignore extensions with an invalid client
>     argument." Why not reject obviously malformed extensions?
>
> Ignoring an extension amounts to rejecting it, since the authenticator 
> won’t see it and therefore won’t respond. Extensions are optional so 
> we don’t want to break core functionality just because the options are 
> not perfect – we’d rather do the core function without the extra option.
>
I disagree on principle here. I think that with security protocols, it 
is better to require strict conformance to the spec, especially when 
you've just defined it. Specifically we've seen attacks that use fuzzing 
techniques and where catching such issues would have blocked the attack.
>
>   * 8.2 Authenticator Selection: The text is unclear. Instead of "If
>     the client supports the Authenticator Selection Extension, it MUST
>     use the first available authenticator whose AAGUID is present in
>     the AuthenticatorSelectionList" I would suggest: "If the client
>     supports the Authenticator Selection Extension, it MUST use the
>     first authenticator from the AuthenticatorSelectionList that is
>     available in the system".
>
> Good point. Please open an issue.
>
#207
>
>   * 8.5: The Location Extension seems to conflict with privacy
>     constraints in mobile operating systems, where a user can allow
>     location information to each application. How do we allow the user
>     to give consent to each RPID separately to access location data?
>
> Managing this is left up to the clients. Clients can strip this 
> extension from sites that do not have permissions to location data.
>
I think it's important enough to point out. Opened #208
>
>