A more secure verifier?

[callahad]

Verifiers (ours included) should probably not accept an assertion signed by a fallback if the domain in question is a native Identity Provider.

This mitigates the security risk of browserid.org being compromised, as fraudulent assertions from browserid.org for users with a native Identity Provider would get rejected.

This question has come up two or three times on the mailing list.

[benadida]

Yes, absolutely. Not probably. Absolutely :)

[boinggg]

like

[warner]

we aren't doing this already? I'll study the code to see where the pubkey lookup is happening and what we do when it succeeds.

One deep question: how "sticky" should it be? Specifically, how long should the verifier remember that it saw an IdP pubkey? If an IdP publishes their key, then gives up and removes it, at what point should the verifier start accepting certs from the fallback? (similarly, how long until the browser's implementation stops trying to talk to the primary and switches to the fallback?)

I've suggested before that the keys published in /.well-known/browserid would benefit from expiration dates.. I think they would help here too, and would behave just like DNS TTLs or HTTP cache headers. If an IdP ever publishes a pubkey, even for just a moment, they should expect browsers and verifiers to pay attention to it until the latest expiration date passes.

We should probably also study the handoff behavior. If at T=0 the browser checks the IdP, sees no .well-known/browserid, uses the fallback, and generates an assertion, then at T=1 the IdP starts publishing their pubkey, then at T=2 the verifier checks that assertion, should it fail? And is there a feedback mechanism to cause the browser to try again, starting with the IdP? For assertions, the window of possible breakage is pretty small (things might be broken for the first 5 minutes after the IdP starts offering browserid service, but after that they'll be ok). For browser certificates, it might be more like a day. Worth studying, at any rate.

[benadida]

@warner we're not doing this yet because we haven't figured out the upgrade behavior completely... but it's worth a careful consideration if you have time!

[seanmonstar]

@warner is this important enough for beta1? And can it be done quickly enough? If not, we should tag it beta2

[warner]

I don't think it can be done quickly enough: I suspect that getting the handoff right will involve revisiting a lot of code (in particular to have the browser implementation respond to expired pubkeys by re-fetching a new key, and maybe copy some of the verification checks into the browser so it can predict what the verifier will do and fix any problems before delivering the assertion).

Also, I think it can wait for beta2, if we don't expect a flood of IdPs to start deploying right away.

I'll move it to beta2-req.

[jonasschneider]

The exclusion policy has to be even stricter than that.

Treating the case of "can't fetch declaration of support doc" as "doesnt' support browserid" opens up a side-channel attack: If an attacker has access to the network between verifier and IdP, it can just block the connection attempt, and thus coerce the verifier into allowing the fallback IdP to vouch for the IdP even though there is native support for BrowserID.

This is a similar problem to the one DNSSEC faced that eventually forced them to introduce the very complicated NSEC/NSEC3 "Authenticated Denial of Existence" system.

This could be mitigated by
a) aggresively caching /.well-known/browserid or
b) double-checking by trying to GET / over the same SSL connection (via Connection: keep-alive). If the request fails as well, the fallback provider should not be allowed to vouch.

[benadida]

@jonasschneider it's not the DNSSEC situation, as best as I can tell. With DNSSEC, an attacker can block network connectivity of a user's machine, and that would be enough to attack them causing fallback to a less-secure protocol. Here, the attacker would have to block connectivity of the web site it wants to attack and also attack the fallback IdP, which is both harder and doesn't results in far less security.

Once we have a better understanding of how this distributed protocol will work/fail, we can make the verifier behave more strictly. But doing so upfront and risking honest users seeing failures doesn't really make sense, in my opinion.

[jaredhirsch]

We're out of dev time for Beta 2. Bumping to Beta 3

[ericelliott]

What's the latest status of this issue? Is it really still open, or did somebody just forget to reference the ticket in the latest pull request?

[callahad]

Hi! To help us better focus, I'm "closing" all issues that have been open for more than six months. These have been tagged "cleanup-2014" so that we can go back and review them in the future.

For more information, check out this thread: http://thread.gmane.org/gmane.comp.mozilla.identity.devel/7394

If you believe this bug is still a major issue for you, please comment, submit a pull request, or discuss it on our mailing list: https://lists.mozilla.org/listinfo/dev-identity

Sorry for GitHub notification spam!

[jonasschneider]

Closing this feels unacceptable for me. I brought it up on the mailing list. Do we have a concrete policy on when not to consult/accept the fallback provider yet?