Add privacy consideration about terminating getAssertion early #687

emlun · 2017-11-13T17:16:10Z

Related issues: #184, #204 . Loosely related: #140 .

This adds a privacy consideration note to §5.1.4. Use an existing credential to make an assertion about the privacy implications of terminating before the timer expires.

The PR also includes some language changes to the waiting condition in both §5.1.3. Create a new credential and §5.1.4. Use an existing credential to make an assertion which are needed to make the privacy consideration text meaningful, and which were probably already intended.

Preview | Diff

The previous language would have the procedure terminate as soon as there are no pending authenticator requests - including immediately at the beginning unless at least one authenticator is available at that time.

kpaulh · 2017-11-13T23:59:42Z

index.bs

+- A named [=public key credential|credential=] is not available.
+- A named [=public key credential|credential=] is available, but the user denies [=user consent|consent=] to use it.
+
+If the above cases are distinguishable, that leaks information by which a malicious [=[RP]=] could identify the user by probing


"that leaks information" -> "information is leaked"?

That sounds better, thanks!

equalsJeffH

Overall this looks fine, thanks. Though:

please merge-from-master
perhaps we should land PR fix #322: flesh out Security Considerations (for now) #705 first since it creates a priv cons section, and add the proposed #getAssertion-privacy-considerations as a priv cons subsection?
normative requirements ought to be in the algorithm itself, rather than buried in priv cons, pls see comment below.

equalsJeffH · 2017-12-06T19:45:17Z

index.bs

+If the above cases are distinguishable, information is leaked by which a malicious [=[RP]=] could identify the user by probing
+for which [=public key credential|credentials=] are available. In particular, the client MUST NOT return a "{{NotAllowedError}}"
+before the |lifetimeTimer| has expired, as that difference in timing would constitute such an information leak.
+


IMV, the latter final normative sentence needs to be stated in the algorithm itself, rather than buried down here in Priv Cons.

equalsJeffH · 2017-12-06T19:50:04Z

Reviewed, modest changes requested: #687 (review)

equalsJeffH · 2017-12-06T19:53:58Z

so this fixes issues: #184, #204 ?

emlun · 2017-12-07T18:49:39Z

Agreed on all three points. I'll finish this up after #705 is merged.

Yes, this fixes #184 and #204, assuming I'm right in interpreting #204 as raising the same concern as #184.

emlun · 2017-12-25T22:06:14Z

@equalsJeffH Please re-review!

equalsJeffH

LGTM modulo nits. thx @emlun !

equalsJeffH · 2017-12-29T15:28:03Z

index.bs

+
+In order to protect the user from being identified without [=user consent|consent=], implementations of the
+{{PublicKeyCredential/[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)}} method need to take care to
+not leak information that could enable the [=[RP]=] to distinguish between the cases:


nit: s/the cases/these cases/

equalsJeffH · 2017-12-29T15:28:33Z

index.bs

+not leak information that could enable the [=[RP]=] to distinguish between the cases:
+
+- A named [=public key credential|credential=] is not available.
+- A named [=public key credential|credential=] is available, but the user denies [=user consent|consent=] to use it.


nit: s/user denies/user does not/

equalsJeffH · 2017-12-29T15:29:55Z

index.bs

+
+If the above cases are distinguishable, information is leaked by which a malicious [=[RP]=] could identify the user by probing for
+which [=public key credential|credentials=] are available. For example, one such information leak is if the client returns a
+failure response as soon as the user denies [=user consent|consent=] to proceed with the operation. In this case the [=[RP]=]


nit: s/user denies/user does not/

equalsJeffH

LGTM, thanks :)

emlun · 2018-01-11T19:40:35Z

@equalsJeffH Reading this again, I'm inclined to revert this one change #687 (comment) to "the user denies consent", as the containing sentence is meant to express "if the client returns a failure in response to the user's action of refusing a prompt for consent". What do you think?

equalsJeffH · 2018-01-12T17:44:38Z

sure, fine with me.

See #687 (comment)

@equalsJeffH

As requested by @equalsJeffH at #736 (comment)

nadalin · 2018-01-17T00:27:58Z

@selfissued please review so we can merge

selfissued

The new privacy section seems fine. But it seems like an incorrect and unrelated change to delete the clause "issuedRequests not empty" in two places. Please don't merge this until this this additional change is either documented and agreed to or removed.

selfissued · 2018-01-17T01:02:50Z

index.bs

@@ -885,8 +885,8 @@ When this method is invoked, the user agent MUST execute the following algorithm

    1. [=set/Append=] |authenticator| to |issuedRequests|.

-1. [=While=] |issuedRequests| [=list/is not empty=], perform the following actions depending upon
-    |lifetimeTimer| and responses from the authenticators:
+1. [=While=] |lifetimeTimer| has not expired, perform the following actions depending upon |lifetimeTimer| and responses from the


Why was the clause "issuedRequests not empty" deleted?

See #687 (comment)

selfissued · 2018-01-17T01:03:37Z

index.bs

@@ -1233,7 +1235,7 @@ When this method is invoked, the user agent MUST execute the following algorithm

    1. [=set/Append=] |authenticator| to |issuedRequests|.

-1. While |issuedRequests| [=list/is not empty=], perform the following actions depending upon |lifetimeTimer|
+1. [=While=] |lifetimeTimer| has not expired, perform the following actions depending upon |lifetimeTimer|


Why was the clause "issuedRequests not empty" deleted?

See #687 (comment)

emlun · 2018-01-17T07:45:30Z

@selfissued Thank you for reviewing. The clause "issuedRequests is not empty" was changed to "lifetimeTimer has not expired" because with the previous language the operation would terminate immediately if no authenticator is present at the moment when the timer is started, but makeCredential step 19 and getAssertion step 17 are intended to be run asynchronously as authenticators appear within the timeout. This change is mostly orthogonal to the addition of the privacy considerations section, but it's necessary for the privacy consideration text to make any sense. I also believe we need to make this change for the algorithms themselves to make sense, even without the new privacy consideration.

selfissued · 2018-01-17T16:50:53Z

Thanks for the explanation, @emlun . Please proceed with the merge.

equalsJeffH · 2018-01-19T18:33:55Z

@emlun wrote in #687 (comment):

Yes, this fixes #184 and #204, assuming I'm right in interpreting #204 as raising the same concern as #184.

Actually, upon further review, I do not believe this PR addressed issue #204, because the latter is in regards to #createCredential aka [[Create]], and this PR addressed privacy concerns at authentication time i.e. #getAssertion aka [[DiscoverFromExternalSource]] aka "authentication ceremonies". See also #184 (comment)

So we still have #204 to address.

emlun · 2018-01-19T20:59:41Z

I believe with hot-plugging makeCredential doesn't have the same information leak anymore, and either way this PR made the same normative changes to both the makeCredential and the getAssertion algorithms. But you're right that the Privacy Considerations subsection only mentions getAssertion, which should be fixed.

My reasoning is the following. The attack would previously be:

The attacker calls makeCredential with some credentials in the excludeCredentials parameter.
The browser notices that one of the excluded parameters is available, and terminates the operation immediately.
The attacker concludes that the user possesses one of the named credentials.

Whereas now, if an excluded credential is available, the browser will simply ignore that authenticator and instead wait for a new authenticator without an excluded credential to appear. If the browser were to violate the spec and return a NotAllowedError as soon as the user denies the prompt (which step 21 now expressly forbids), the attack would be:

The attacker calls makeCredential with some credentials in the excludeCredentials parameter.
The browser notices that one of the excluded parameters is available, ignores that authenticator and waits for another to appear.
The user plugs in a new authenticator.
The browser asks the user if they want to create a credential on that authenticator.
The user denies the prompt.
The browser returns a NotAllowedError to the attacker.
The attacker notices that a NotAllowedError was returned before the timer expired.
- The attacker can conclude that the user has an authenticator that does not contain one of the named credentials.
- The attacker cannot conclude that the user has an authenticator that contains one of the named credentials.
- The attacker cannot conclude that the user does not have an authenticator that contains one of the named credentials.

I suppose this conclusion could perhaps be combined with some external assumptions (like an upper limit on how many authenticators a user is likely to own) to narrow the field to some extent, possibly enough to identify a single user. But again, this should also not be possible if the browser never returns the NotAllowedError before the timer expires.

Please let me know if you spot any errors in the above reasoning. :)

equalsJeffH · 2018-01-19T23:03:42Z

Thanks @emlun for your detailed analysis above. I had not reviewed the diff closely enough and had focused on the added Authentication Ceremonies privacy considerations subsection rather than the revised lifetime timer stipulations in both #createCredential aka [[Create]] and #getAssertion aka [[DiscoverFromExternalSource]]. For #createCredential aka [[Create]] these are steps 20 and 21. mea culpa!

I agree with the overall conclusion of the detailed analysis above: a malicious RP (aka "the attacker") will not learn anything through seeding of the excludeCredentials list because any returned NotAllowedErrors are returned after the lifetimeTimer has expired, regardless of the user's actions (see step 21).

It seems, IIUC, there are a couple detail-level issues with the steps in the detailed analysis above, but they do not AFAICT affect this conclusion.

Here they are for completeness' sake:

The browser notices that one of the excluded parameters is available, ignores that authenticator and waits for another to appear.

AFAICT, the browser/client-platform does not do this (see #createCredential steps 19.5 and 19.6), rather the authnr does this (see authenticatorMakeCredential step 3), and returns NotAllowedError, which is handled by #createCredential step 20 switch branch "If any authenticator returns an error status".

The browser asks the user if they want to create a credential on that authenticator.

nit: AFAICT the spec does not stipulate whether the browser, client platform, or authenticator prompts the user.

The browser returns a NotAllowedError to the attacker.

The attacker notices that a NotAllowedError was returned before the timer expired.

Ah, but the imperative "this step MUST NOT be executed before lifetimeTimer has expired" language this PR inserted into #createCredential step 21 means that the error is not returned before the timer expires, yes? (which makes the above analysis stronger).

thanks again.

emlun · 2018-01-20T00:07:53Z

Thanks for your detailed response!

The browser notices that one of the excluded parameters is available, ignores that authenticator and waits for another to appear.

AFAICT, the browser/client-platform does not do this [...] rather the authnr does this [...] and returns NotAllowedError

Ah yes, that is correct. Either way, the end result is that the client ignores the authenticator in question and keeps waiting for another candidate.

nit: AFAICT the spec does not stipulate whether the browser, client platform, or authenticator prompts the user.

Indeed, although authenticatorMakeCredential step 6 softly specifies that the authenticator does it if capable, and otherwise the client. I chose to keep it simple because I don't know of existing authenticator hardware that allows active denial of consent (as opposed to passive denial by timeout).

Ah, but the imperative [...] this PR inserted into #createCredential step 21 means that the error is not returned before the timer expires, yes? [...]

Assuming implementers read and implement all the steps, yes. :)

emlun added 2 commits November 13, 2017 17:39

Wait for lifetimeTimer to expire instead of issuedRequests to be empty

18847d5

The previous language would have the procedure terminate as soon as there are no pending authenticator requests - including immediately at the beginning unless at least one authenticator is available at that time.

Add privacy consideration about terminating getAssertion early

3a8f961

emlun added privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. subtype:algorithms/WebIDL subtype:privacy type:technical labels Nov 13, 2017

emlun added this to the CR milestone Nov 13, 2017

emlun requested a review from selfissued November 13, 2017 17:16

Clarify that the privacy consideration is a timing issue

df7dc0f

emlun mentioned this pull request Nov 13, 2017

Privacy concerns with blacklist/whitelist #184

Closed

kpaulh reviewed Nov 14, 2017

View reviewed changes

Address review comment by @kpaulh

96655eb

emlun mentioned this pull request Nov 17, 2017

#createCredential alg: "if options.authenticatorSelection is present..." may be incorrect #692

Closed

emlun mentioned this pull request Nov 29, 2017

Authenticator selection extension - should makeCredential fail if no specified authenticator can be found? #227

Closed

equalsJeffH suggested changes Dec 6, 2017

View reviewed changes

nadalin assigned emlun Dec 8, 2017

emlun added 3 commits December 25, 2017 22:08

Merge branch 'master' into issue-184

73b9e4f

Move getAssertion privacy considerations to Security Considerations

1214398

Move normative language from priv-cons into algorithms

38e2c4f

equalsJeffH approved these changes Dec 29, 2017

View reviewed changes

Address review comments by @equalsJeffH

2752db2

equalsJeffH approved these changes Jan 1, 2018

View reviewed changes

emlun mentioned this pull request Jan 3, 2018

Change "denies consent" to "does not consent" #735

Merged

emlun added 2 commits January 11, 2018 16:10

Merge branch 'master' into issue-184

f7bc2f8

Fix typo

8ee452c

equalsJeffH removed the subtype:privacy label Jan 11, 2018

Revert one "denies consent" => "does not consent" change

fb749d8

See #687 (comment)

emlun mentioned this pull request Jan 12, 2018

Fix typo #736

Closed

Copy changes from #736

f716b7f

As requested by @equalsJeffH at #736 (comment)

selfissued requested changes Jan 17, 2018

View reviewed changes

selfissued approved these changes Jan 17, 2018

View reviewed changes

emlun merged commit 51ec228 into master Jan 17, 2018

emlun deleted the issue-184 branch January 17, 2018 16:53

WebAuthnBot pushed a commit that referenced this pull request Jan 17, 2018

Built by Travis-CI: 51ec228 Merge pull request #687 from w3c/issue-184

6f88ff2

This was referenced Jan 19, 2018

Allow hot-plugged authenticators? #613

Closed

document preventions of RP-driven de-anonymization attempts in privacy-cons #743

Closed

equalsJeffH mentioned this pull request Jan 19, 2018

Privacy across Account IDs #204

Closed

emlun mentioned this pull request Jan 26, 2018

providing info about authenticator availability / attachments #764

Closed

equalsJeffH mentioned this pull request Feb 6, 2018

fix #204: factor makeCred into reg & authn priv considerations #777

Merged

emlun mentioned this pull request Feb 16, 2018

RPs cannot show "You've Already Registered This Authenticator" Message #806

Closed

emlun mentioned this pull request Apr 24, 2018

NULL or DOMException #876

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add privacy consideration about terminating getAssertion early #687

Add privacy consideration about terminating getAssertion early #687

emlun commented Nov 13, 2017 •

edited by pr-preview bot

kpaulh Nov 13, 2017

emlun Nov 14, 2017

equalsJeffH left a comment

equalsJeffH Dec 6, 2017

equalsJeffH commented Dec 6, 2017

equalsJeffH commented Dec 6, 2017

emlun commented Dec 7, 2017

emlun commented Dec 25, 2017

equalsJeffH left a comment

equalsJeffH Dec 29, 2017

equalsJeffH Dec 29, 2017

equalsJeffH Dec 29, 2017

equalsJeffH left a comment

emlun commented Jan 11, 2018

equalsJeffH commented Jan 12, 2018

nadalin commented Jan 17, 2018

selfissued left a comment

selfissued Jan 17, 2018

emlun Jan 17, 2018

selfissued Jan 17, 2018

emlun Jan 17, 2018

emlun commented Jan 17, 2018

selfissued commented Jan 17, 2018

equalsJeffH commented Jan 19, 2018

emlun commented Jan 19, 2018

equalsJeffH commented Jan 19, 2018 •

edited

emlun commented Jan 20, 2018

Add privacy consideration about terminating getAssertion early #687

Add privacy consideration about terminating getAssertion early #687

Conversation

emlun commented Nov 13, 2017 • edited by pr-preview bot

Choose a reason for hiding this comment

Choose a reason for hiding this comment

equalsJeffH left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

equalsJeffH commented Dec 6, 2017

equalsJeffH commented Dec 6, 2017

emlun commented Dec 7, 2017

emlun commented Dec 25, 2017

equalsJeffH left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

equalsJeffH left a comment

Choose a reason for hiding this comment

emlun commented Jan 11, 2018

equalsJeffH commented Jan 12, 2018

nadalin commented Jan 17, 2018

selfissued left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emlun commented Jan 17, 2018

selfissued commented Jan 17, 2018

equalsJeffH commented Jan 19, 2018

emlun commented Jan 19, 2018

equalsJeffH commented Jan 19, 2018 • edited

emlun commented Jan 20, 2018

emlun commented Nov 13, 2017 •

edited by pr-preview bot

equalsJeffH commented Jan 19, 2018 •

edited