5 ms·

I've just read through the Persona protocol specification document at https://github.com/mozilla/id-specs/blob/prod/browserid/index.md https://github.com/mozill

I've just read through the Persona protocol specification document at https://github.com/mozilla/id-specs/blob/prod/browserid/index.md https://github.com/mozilla/id-specs/blob/prod/browserid/inde... and was quite disappointed to find RFC5785 in use, in which HTTP is abused as an infrastructure discovery protocol. This gives a lie to the identity being an "email address". It isn't. Ok, it's structured as a LHS@RHS form but the domain in the RHS isn't an email domain, it's an overloaded website with some problematic assumptions ladled in. This creates a significant barrier to adoption. Many entities just won't bother: not only does it ask an apex A record to serve actual content (usually a mistake) but it requires the primary web host of a registerable domain, usually a trademark or brand identity, to carry technical material, definitely a clash of concerns. (Why? In many companies of reasonable size, the website is managed by a completely different group of people - often a marketing team - to the internal identity service. Then, even if one team convinces to the other to install the browserid file, there is a possibility of it being deleted it by mistake during the next site refresh.) I had hoped to find an intermediate step where a DNS SRV lookup was used to first locate the host delivering the browserid file. This follows the federated structure of email rather more closely and allows the identity service to be independent of the corporate brochureware. Even better - if the SRV lookup could be signed with DNSSEC, the transfer itself can be protected with DANE. The whole thing becomes manageable as a simple, separate unit of technology. It is thus rather more likely to gain the support of system administrators.

wmf 14y ago
Can JavaScript look up a SRV record?
- IgorPartola 14y ago
  Only with the help of a server.
- inopinatus 14y ago
  Javascript can (ISTR there is a pure JS DNS library for node) but perhaps not in the browser without specific browser support. You can say the same about trustworthy crypto, incidentally. SRV is definitely the ideal record. In this case I can see why a pure HTTP approach was chosen (it avoids browser dependancies) and it irks me that developers of web-based tools tend to develop inside the HTTP bubble rather than using the broad and highly capable infrastructure of the Internet, because this kind of constraining outcome is the result. SRV would be an excellent choice for HTTP/2.0 as well, rescuing us all from apex quasi-CNAME hacks and the like. However in my initial remark you can substitute in the use of "a well-known subdomain"[1] for "SRV record" and still achieve a better separation of concerns than simply using the RHS of the identity string. [1] c.f. DKIM's slightly hackish but effective use of an intermediate underscore to denote infrastructure DNS entries. Won't work for A records though IIRC.
shardling 14y ago
>This creates a significant barrier to adoption. No, not really. Because Mozilla is running the Fallback server in the meantime.
- inopinatus 14y ago
  On the contrary, it means that companies (already deterred by the technical issues) don't even have to bother. It's actually another barrier to entry, only more subtle. It's an incentive not to bother deploying an IdP, which is the adoption I'm talking about and that is necessary to call it "federated". One might liken it to government subsidies for the incumbents in an industry. There's no "meantime" here - unless a Very Large Social Network adopts this protocol, I suspect the Fallback server will be the IdP most people use.
  - jackalope 14y ago
    Even worse, Persona promises that "Developers get a verified email address for all of their users," which might be mistakenly construed as some degree of identity assurance, which can't be guaranteed by this system at all, especially when a fallback is involved.
badida 14y ago
We're discussing the addition of a DNS discovery option. Not clear yet that this is something that can be secured as well as HTTPS discovery (which I don't consider abusive, given the number of systems that do it already.) But it's on our radar: https://github.com/mozilla/browserid/issues/1523 https://github.com/mozilla/browserid/issues/1523
- jackalope 14y ago
  But requesting a resource without knowing it exists is abusive, and the fact that more and more developers think it's an appropriate means of discovery is becoming a serious problem. It saps resources, fills logs with noise, and can trigger intrusion detection systems. I don't think the Persona project recognizes what a barrier to entry the lack of a reasonable discovery method really is. There are a host of potential issues: 1. For the alice@example.com identifier, it assumes that example.com has an A record. Many, many organizations choose not to have an A record at the top level, while still publishing an MX record to support email addresses. 2. If there is an A record, it assumes that there is a web server listening on port 443. If there isn't, /.well-known/browserid can't be retrieved. What is the fallback mechanism, and how does it affect our users if we adopt Persona in the future? What if this probe is flagged by an IDS, blacklisting the source IP? 3. If there is a web server listening on port 443, it assumes that it will serve resources for example.com. What if it doesn't and gets the /.well-known/browserid from the default host, which is an entirely different domain? What if this probe for an unsupported host is flagged by an IDS, blacklisting the source IP? What if example.com isn't the CN or a SubjectAltName in the SSL certificate? Is the certificate validated? Do I now have to purchase a commercial certificate for a domain that I never intended to be a web site? 4. When a user first enters an identifier, such as alice@example.com, it assumes this is not only a valid email address, but a valid login. What happens if a user has used an email alias in the fallback that cannot be used to authenticate in our system when we adopt Persona? What if the organization doesn't support Persona, and doesn't want its domain used in the fallback mechanism? Is there an inherent identity theft risk in using a fallback system? Can a rogue web developer create a temporary /.well-known/browserid and backend that will allow them to authenticate as anyone at the organization, then cover their tracks by removing the file? All of these issues can be neatly solved with DNS discovery. If an organization wants to support Persona, let it publish an SRV record. If one doesn't exist, Persona should tell the user, "Your domain does not support Persona."
mook 14y ago
The identity indeed doesn't have to be an email address; I'm currently using a random thing I set up on AppEngine's free tier (serving a static file for the public side; the auth side is client-local). There's no way I'll be receiving @*.appspot.com mail. Of course, this also means my identity is tied to a domain I don't control and might go away at any point with no warning... I do think that the Persona developers are conflating identity with e-mail too much; I can't use it for Mozilla's bug tracker, for example, because I actually value receiving mail and they have no plans to have split identity/e-mail information.
saljam 14y ago
I agree. To me, Webfinger+OpenID seems like a more sensible solution. At least in principle. The only downside is that OpenID lacks BrowserID's privacy bits. http://code.google.com/p/webfinger/ http://code.google.com/p/webfinger/
- Gmo 14y ago
  > The only downside is that OpenID lacks BrowserID's privacy bits. Well, that's quite a major downside, don't you think ? Isn't one of the main purpose of persona/BrowserId a better respect of privacy ?
- drdaeman 14y ago
  I believe http://gpgauth.org/ http://gpgauth.org/ is better (except that it lacks strong community and PR from browser vendors). No need for per-site passwords (the only passwords are master password and, possibly, secret for key escrow). No need for any discovery and third parties, as you're identified by your own key, which contains a name (or nickname or whatever) — the most natural approach to identities (which has minor problem with nickname collisions, but that's about it). And, privacy-wise — no need to reveal email address if you don't want it, too. Edit/Add: WebID looks even more nice http://webid.info/ http://webid.info/, as it's actively developed by W3C WebID Community Group, while gpgAuth development is stalled and project seems dead.
  - saljam 14y ago
    Wow, I remember reading about foaf+ssl years ago. Glad to see it's still alive!

wmf 14y ago

Can JavaScript look up a SRV record?

IgorPartola 14y ago
Only with the help of a server.
inopinatus 14y ago
Javascript can (ISTR there is a pure JS DNS library for node) but perhaps not in the browser without specific browser support. You can say the same about trustworthy crypto, incidentally. SRV is definitely the ideal record. In this case I can see why a pure HTTP approach was chosen (it avoids browser dependancies) and it irks me that developers of web-based tools tend to develop inside the HTTP bubble rather than using the broad and highly capable infrastructure of the Internet, because this kind of constraining outcome is the result. SRV would be an excellent choice for HTTP/2.0 as well, rescuing us all from apex quasi-CNAME hacks and the like. However in my initial remark you can substitute in the use of "a well-known subdomain"[1] for "SRV record" and still achieve a better separation of concerns than simply using the RHS of the identity string. [1] c.f. DKIM's slightly hackish but effective use of an intermediate underscore to denote infrastructure DNS entries. Won't work for A records though IIRC.

shardling 14y ago

>This creates a significant barrier to adoption. No, not really. Because Mozilla is running the Fallback server in the meantime.

inopinatus 14y ago
On the contrary, it means that companies (already deterred by the technical issues) don't even have to bother. It's actually another barrier to entry, only more subtle. It's an incentive not to bother deploying an IdP, which is the adoption I'm talking about and that is necessary to call it "federated". One might liken it to government subsidies for the incumbents in an industry. There's no "meantime" here - unless a Very Large Social Network adopts this protocol, I suspect the Fallback server will be the IdP most people use.
- jackalope 14y ago
  Even worse, Persona promises that "Developers get a verified email address for all of their users," which might be mistakenly construed as some degree of identity assurance, which can't be guaranteed by this system at all, especially when a fallback is involved.

badida 14y ago

We're discussing the addition of a DNS discovery option. Not clear yet that this is something that can be secured as well as HTTPS discovery (which I don't consider abusive, given the number of systems that do it already.) But it's on our radar: https://github.com/mozilla/browserid/issues/1523 https://github.com/mozilla/browserid/issues/1523

jackalope 14y ago
But requesting a resource without knowing it exists is abusive, and the fact that more and more developers think it's an appropriate means of discovery is becoming a serious problem. It saps resources, fills logs with noise, and can trigger intrusion detection systems. I don't think the Persona project recognizes what a barrier to entry the lack of a reasonable discovery method really is. There are a host of potential issues: 1. For the alice@example.com identifier, it assumes that example.com has an A record. Many, many organizations choose not to have an A record at the top level, while still publishing an MX record to support email addresses. 2. If there is an A record, it assumes that there is a web server listening on port 443. If there isn't, /.well-known/browserid can't be retrieved. What is the fallback mechanism, and how does it affect our users if we adopt Persona in the future? What if this probe is flagged by an IDS, blacklisting the source IP? 3. If there is a web server listening on port 443, it assumes that it will serve resources for example.com. What if it doesn't and gets the /.well-known/browserid from the default host, which is an entirely different domain? What if this probe for an unsupported host is flagged by an IDS, blacklisting the source IP? What if example.com isn't the CN or a SubjectAltName in the SSL certificate? Is the certificate validated? Do I now have to purchase a commercial certificate for a domain that I never intended to be a web site? 4. When a user first enters an identifier, such as alice@example.com, it assumes this is not only a valid email address, but a valid login. What happens if a user has used an email alias in the fallback that cannot be used to authenticate in our system when we adopt Persona? What if the organization doesn't support Persona, and doesn't want its domain used in the fallback mechanism? Is there an inherent identity theft risk in using a fallback system? Can a rogue web developer create a temporary /.well-known/browserid and backend that will allow them to authenticate as anyone at the organization, then cover their tracks by removing the file? All of these issues can be neatly solved with DNS discovery. If an organization wants to support Persona, let it publish an SRV record. If one doesn't exist, Persona should tell the user, "Your domain does not support Persona."

mook 14y ago

The identity indeed doesn't have to be an email address; I'm currently using a random thing I set up on AppEngine's free tier (serving a static file for the public side; the auth side is client-local). There's no way I'll be receiving @*.appspot.com mail. Of course, this also means my identity is tied to a domain I don't control and might go away at any point with no warning... I do think that the Persona developers are conflating identity with e-mail too much; I can't use it for Mozilla's bug tracker, for example, because I actually value receiving mail and they have no plans to have split identity/e-mail information.

saljam 14y ago

I agree. To me, Webfinger+OpenID seems like a more sensible solution. At least in principle. The only downside is that OpenID lacks BrowserID's privacy bits. http://code.google.com/p/webfinger/ http://code.google.com/p/webfinger/

Gmo 14y ago
> The only downside is that OpenID lacks BrowserID's privacy bits. Well, that's quite a major downside, don't you think ? Isn't one of the main purpose of persona/BrowserId a better respect of privacy ?
drdaeman 14y ago
I believe http://gpgauth.org/ http://gpgauth.org/ is better (except that it lacks strong community and PR from browser vendors). No need for per-site passwords (the only passwords are master password and, possibly, secret for key escrow). No need for any discovery and third parties, as you're identified by your own key, which contains a name (or nickname or whatever) — the most natural approach to identities (which has minor problem with nickname collisions, but that's about it). And, privacy-wise — no need to reveal email address if you don't want it, too. Edit/Add: WebID looks even more nice http://webid.info/ http://webid.info/, as it's actively developed by W3C WebID Community Group, while gpgAuth development is stalled and project seems dead.
- saljam 14y ago
  Wow, I remember reading about foaf+ssl years ago. Glad to see it's still alive!