[badida]

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

[jackalope]

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 [e-mail] 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 [e-mail], 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."

[badida]

The are all good arguments, and again I want to point out that we are considering them. But there is a big security concern with DNS spoofing (and DNSSEC is not quite easy yet.) So it's not an obvious decision.

[belorn]

On top of the arguments of jackalope, I would like to add one more.

For many domains, the A record do not go directly to the actually webserver of the company. Many domain has redirects for SEO reasons, and often get this services directly by their DNS provider (and often do not allow https). Persona prevents this kind of setup. I am also a bit curios if a certificate under one domain can verify a email user of an different domain.

[inopinatus]

The DNS spoofing threat already existed; you have TLS as a partial mitigation. DNSSEC w/DANE is a better mitigation. (Ok, plenty of warts in DNSSEC but it is available today). I'd be more worried about the malicious web developer threat - it's almost trivial to exploit.

Generally - if one is going to throw around the word "federated" but without properly leveraging the DNS, then the wheel is probably being reinvented; along with a host of layering violations that result in the many misbehaviours discussed here.

The absence of SRV lookup capability in Mozilla is open issue (bug #14328) since 1999.