DNS-based delegation of the Support Document

[lloyd]

Multiple people have requested this. Let's explore this idea with a concrete proposal.

Assigning @fmarier, cause this is kinda his bag!

[callahad]

I'm concerned about library authors managing the additional complexity that this introduces. How can we make it sufficiently simple?

@vthunder Suggested that people should just download and locally run our verifier.

[fmarier]

My feeling on this is that just like developers usually don't write their own crypto, they would hopefully use a verification library and not write their own.

[jcea]

I am interested, for instance of being able to delegate the BrowserID identity provider to a subdomain.

My email is jcea@jcea.es. I would rather prefer to provide identity proof thru "browserid.jcea.es" instead of "jcea.es" webserver.

[vthunder]

Let's put this on the table for beta 2?

It'd be nice to be able to set up the delegation without having to run a server.

[qmx]

@fmarier would the idea be something like this?

_persona._tcp.domain. 86400 IN 0 5 443 another.domain.tld

[fmarier]

@qmx Yes, that's the kind of thing (SRV record) I had in mind.

[jaredhirsch]

Not happening prior to Beta 2. Bumping to Beta 3.

[lloyd]

+1 from irc:

[15:38:01] <janfrode>    DNS would be great..

[janfrode]

I'm working for an ISP, hosting quite a few mail domains. Many second level domain-names are already taken by various websites which isn't running HTTPS, and if they do we likely only have the www.example.com name in the cert. For partner domains that are already running plain http for www.example.com, it will be problematic to suddenly occupy example.com with a ssl-enabled web service.

IMHO SRV-records would be the natural place to do delegation. It would also be a nice push to get DNSSEC deployed more.

[qmx]

so how are the concrete next steps to make this happen? just finding the time to do it? maybe I can help to bootstrap this part with some guidance...

[lloyd]

Concrete steps - run it through the identity list one last time to surface and major objections - then implement and send a pull request.

We will also need to create a way to test in an automated fashion, but that should be pretty doable.

-- lloyd (thumb-typing)

On Apr 9, 2013, at 6:02 PM, Douglas Campos notifications@github.com wrote:

so how are the concrete next steps to make this happen? just finding the time to do it? maybe I can help to bootstrap this part with some guidance...

— Reply to this email directly or view it on GitHub.

[glondu]

Another thing that uses DNS and /.well-known/ http://tools.ietf.org/html/draft-daboo-srv-caldav-10

[robn]

Adding a +1 to this. If we (FastMail) were ever to be a Persona identity provider we'd absolutely require this. We host hundreds of domains, many of them not owned by us. We don't have any desire to acquire enough IP addresses and certificates (and/or provide processes to let our users acquire/install certificates) to make https:///.well-known work. SRV records is the right way to do this.

[callahad]

we (FastMail)

@robn Well, that's about all the encouragement I need. We'll get this done. It may be a few months (much of the team is focused on FirefoxOS integration and moving infrastructure to AWS), but we'll absolutely get there. I'd also appreciate feedback if there's anything more we can do to make it easy for FastMail to jump on board.

[robn]

@callahad Well that's good news. Though obviously I'm not committing to anything ;)

We do actually have some concerns/questions, which might be legitimate, but also might just be us not fully understanding how this all fits together. We're still discussing it internally. I will likely contact someone (you?) privately to run a few things by you if you don't mind.

[lloyd]

Howdy Robert,

If you have questions you'd prefer to discuss privately, you are more than welcome to email callahad@ and lloyd@ mozilla.com - between us we can get you the answers you need. Exciting prospect!

-- lloyd (thumb-typing)

On May 29, 2013, at 12:37 AM, Robert Norris notifications@github.com wrote:

@callahad Well that's good news. Though obviously I'm not committing to anything ;)

We do actually have some concerns/questions, which might be legitimate, but also might just be us not fully understanding how this all fits together. We're still discussing it internally. I will likely contact someone (you?) privately to run a few things by you if you don't mind.

— Reply to this email directly or view it on GitHub.

[vthunder]

Happy to assist on the side if there's anything I can help with! :-)

[lloyd]

Yeah this is just one of those things we gotta get done.... we need a patch+proposal, and to land it...

[fmarier]

Here's a concrete proposal for how this could work: https://etherpad.mozilla.org/biBsW5BjLQ

I would especially like to get feedback on these two points:

• HTTPS always has precedence over DNS (since the latter can more easily be spoofed/poisoned).
• Use of an SRV record instead of a TXT record.

[robn]

From a quick read through this looks ok to me.

HTTPS taking precedence means I can publish DNS records and support documents for all my users, but if they can use a different identity provider by just publishing something on their website, which is generally going to be much easier for them than changing their DNS entries.

SRV is fine. Its the right way to do it.

Are there any extra considerations for delegated support documents? I don't think so, but I'm still fairly new here.

[janfrode]

@fmarier

Non-DNSSEC can be spoofed, like HTTP can be MITM'ed. DNSSEC can't be spoofed, like HTTPS can't be MITM'ed.

It seems strange to give the existense of a folder on a webserver precedence over a DNS-admin configured SRV record. It means the web-developers/admins might inadvertently break browserid for all users of a domain. I would classify configuring DNS-record a more security related operation, than publishing webpages. I would be more likely to outsource web-development, than configuring DNS-records. But I wouldn't like that this outsourcing give access to mess with browserid.

What happens when the .well-known is there, but non-working? Fallback to DNS records, or broken system? Is it allowed to do delegation to another server on the webserver, when DNS-records are in place?

[fmarier]

What happens when the .well-known is there, but non-working? Fallback to DNS records, or broken system? Is it allowed to do delegation to another server on the webserver, when DNS-records are in place?

What my proposal currently says is that if there is a .well-known/browserid file (whether it's empty, broken, or misconfigured), then what's in DNS is ignored. DNS is only looked at if that file is missing (HTTP 404) or the web server is not serving anything on HTTPS.

[janfrode]

It seems very weak that one is then allowed to compromise a DNSSEC configured system by placing a plain text, unsigned delegated support document on a webserver. Where "a webserver" here is a webserver that is used for hosting lots and lots of stuff, not the locked down authentication webserver we're pointing our DNS records at.

[glondu]

@fmarier Your proposal still requires an HTTPS server running somewhere, and serving a certificate trusted by Mozilla, right? There should be a way to avoid that...

[ozten]

Trying HTTPS first is probably the right thing, but is less desirable from an implementation point of view. Depending on the setup, some sites take a really long time to error out or send a 404, which means we have to wait for HTTPS discovery to timeout, before we can use information from DNS. Probably not that big of a deal.

[callahad]

@janfrode What order would you check things in?

[qmx]

@callahad DNS has bigger priority hands down IMO

[callahad]

But what if unsecured DNS disagrees with TLS-secured HTTPS?

[janfrode]

I would clearly prefer DNS before HTTPS. It should be a nice encouragement to implement DNSSEC..

-jf

Den 6. juni 2013 kl. 18:13 skrev Dan Callahan notifications@github.com:

@janfrode What order would you check things in?

— Reply to this email directly or view it on GitHub.

[fmarier]

@glondu Correct, a support document served over HTTPS is still required. This proposal is not about replacing the support document but rather about letting domains use DNS to delegate the authority from one domain to another. I have updated the bug title.

@ozten My proposal suggests that verifiers do both lookups in parallel to minimize that latency, but you're right, verifiers would have to be careful about timeouts. Given that verifiers will typically be able to cache the support document for a while, I'm also unsure how big of a problem that will be. It certainly won't be any worse than what we have currently though.

Let's take the DNS v. HTTPS precedence discussion to the list: https://groups.google.com/d/topic/mozilla.dev.identity/dP44TDzBnhI/discussion

[chemistrydioxide]

This would be useful for domains which run a non-SSL web server. It would also be a way to run a multi-domain IdP without the need for several IPs.

[seanmonstar]

It'd also allow the many cases like me, where my main domain is pointed at Tumblr, so I can't add a well-known file to it, but can easily point a DNS record to another server that only does my personal auth. On Jun 26, 2013 3:07 PM, "chemistrydioxide" notifications@github.com wrote:

This would be useful for domains which run a non-SSL web server. It would also be a way to run a multi-domain IdP without the need for several IPs.

— Reply to this email directly or view it on GitHubhttps://github.com/mozilla/browserid/issues/1523#issuecomment-20083775 .

[callahad]

Okay, so here's what needs to happen:

• [x] Post a concrete proposal for what the DNS record should look like on the dev-identity mailing list.
• [ ] Write code to do DNS-based lookup for delegation.
• [ ] Determine precedence order for DNS vs HTTPS documents, via discussion on dev-identity.
• [ ] Modify code to respect that precedence.

We can start on the first two now, and @qmx has volunteered to get the ball rolling on that.

We can also start the precedence discussion now. I'll try to summarize and post to dev-identity on that topic tomorrow.

[skorokithakis]

I am vehemently opposed to using any sort of plain DNS. It will undermine the security of the entire protocol, no matter what takes precedence (the attacker can just block port 443 on that webserver and force poisoned DNS to take precedence, completely breaking Persona.

DNSSEC is probably fine, and should probably take precedence, but it's a bit of a hassle to set up (more so than HTTPS). That said, I don't see why it shouldn't be used by whomever wants to use it.

However, I feel that I need to repeat this, for absolute clarity: Do not, under any circumstances, use plain DNS.

[callahad]

Good news, then :) I need to dig up the appropriate link (will add to this later today; about to go catch a flight), but we've decided that we can't do plain DNS for the reasons you cited.

[skorokithakis]

Yaaay, the protocol is saved! Great, I'm looking forward to DNSSEC, thanks.

[robn]

Sucks. I guess I'll have to get moving on DNSSEC then.

[callahad]

I know. :( We're not comfortable with the security implications at the moment. Full discussion on the mailing list: https://groups.google.com/d/msg/mozilla.dev.identity/dP44TDzBnhI/3MijAKI1oR8J

[inopinatus]

Just came here after https://news.ycombinator.com/item?id=7243155. I'll repeat some of my remarks from there.

Elephant in the room: Persona is already using plain DNS to find the IdP https listener to fetch the support document.

So the trust comes from verifying the certificate. If you use SRV records to locate the support document, you'd still fetch that from an https listener and verify the certificate used.

Including DNSSEC with DANE/TLSA still adds value, though, because you gain the ability to validate self-signed certificates from the DNS using an open standard. And that would make ISPs very happy, being able to self-issue the certificate rather than needing a commercial CA cert for each domain served. However, browser support required for this option.

[skorokithakis]

The difference is that you're introducing a vulnerability: If my identifier is me@mydomain.com, Persona verifies the cert at mydomain.com. If an attacker hijacks my DNS (easy to do) and adds an SRV record to attackerdomain.com, then all he has to do is have a valid certificate for attackerdomain.com, and he has everything I own.

You can see how this is a pretty huge hole, because the problem isn't the SSL cert, it's knowing which domain to look for one in. You've just introduced an untrusted mechanism that is able to change the authoritative domain to any other domain. No amount of SSL certs on your site will save you from unauthenticated DNS.

EDIT: Unless you mean your domain, mydomain.com will have an SRV record to myidp.com, which has an SSL certificate for mydomain.com (i.e. a certificate invalid for myidp.com). That would technically work, but be awkward and break a bunch of stuff that assumes valid certs.

[inopinatus]

No, man, the SSL cert needed is still the one for mydomain.com not attackerdomain.com. This attack therefore fails. That's how SRV records work - they're like a sophisticated CNAME, not a 30x redirect.

Only, you can't use a CNAME at the apex of a domain. That's a major factor behind why SRV records were invented. (they solved some other problems along the way)

[inopinatus]

In response to your edit, I have to say I think you've misunderstood the SRV mechanism because that's actually exactly how it works and how it is supposed to work. There's no "technically work" about it - that's how SRV records function. You seem to have confused them with something that operates like a 30x redirect, where one name is substituted for another. That's not the case. SRV records work like CNAMEs, they specify "for that service, at that domain name, you can talk to any of these servers". Rather than going into any more depth or detail I suggest reading the RFC: http://tools.ietf.org/search/rfc2782

[skorokithakis]

So you're proposing a way to discover mydomain.com? Persona already does that now (it's the default). Sounds like you're only trying to work around using a CNAME for a naked domain.

Your proposed solution wouldn't work for anything else. If I want to have a thirdd party as my IdP, (say, persowna.net), using an SRV record for the would either not work or be vulnerable. I could pretty much only specify a host that had a valid SSL cerditicate for mydomain.com as my IdP, which is a limitation Persona currently doesn't have.

[skorokithakis]

What you're misunderstanding is that Persona is able to use any server as your identity provider, you just have to delegate your identity to it.

How would I securely delegate my authority to persowna.net with an SRV record? The IdP would have to have a valid certificate for mydomain.com anyway.

This issue is about DNS-based delegation, not just discovery of the original IdP.

[inopinatus]

I really think you should read the SRV RFC - it's a very simple mechanism. You just delegate something like this in your DNS:

$ORIGIN mydomain.com.
....
_browserid._tcp     IN      SRV 0 0 443 sd-host.persowna.net.
_browserid._tcp     IN      SRV 0 0 443 sd-host2.persowna.net.

then have the browser interpret this record as an instruction to do the following:

• Connect to sd-host.persowna.net (or sd-host2 etc) on port 443
• Make a request for https://mydomain.com/.well-known/browserid
• Validate the mydomain.com certificate of the response.
• Proceed with the returned support document as before

This is exactly what DNS CNAMEs achieve. However, you can't use a CNAME because that would redirect all requests for http://mydomain.com i.e. your entire website. Instead, this allows the support document to be hosted somewhere other than an TLS-secured root of an apex record website, which is a showstopper in at least four ways and a huge problem.

Yes, the host of the support document needs a valid certificate for mydomain.com, but then, it always did, didn't it?

Also, sorry, pasto - I linked an obsolete version of the standard earlier. Should be RFC 2782.

[skorokithakis]

I know how SRV records work :(

Yes, the host of the support document needs a valid certificate for mydomain.com, but then, it always did, didn't it?

Yes and no: you're conflating two issues. One is using SRV records to discover the primary domain/webserver, which is fair enough, it would be a good fallback if the A lookup failed.

The other issue, the one discussed here (i.e. issue 1523), is allowing pure DNS-based delegation, i.e. not needing a support document at all. You would look up mydomain.com, that would say "hey, all my Persona identification is handled by persowna.net, go there", and the client would just go there, never having received an SSL certificate for mydomain.com.

The SRV thing you're talking about is probably a good idea and could be implemented relatively easily. The DNS-based delegation this issue is discussing is what I explained above, and it cannot be solved without DNSSEC.

EDIT: I'm not affiliated with Mozilla or Persona. I'm just a guy who's watching this issue and had some spare time.

[inopinatus]

I have to contradict, @fmarier says very clearly above "this proposal is not about replacing the support document".

[skorokithakis]

He means at the final IdP. Read the chain, especially this:

What my proposal currently says is that if there is a .well-known/browserid file (whether it's empty, broken, or misconfigured), then what's in DNS is ignored. DNS is only looked at if that file is missing (HTTP 404) or the web server is not serving anything on HTTPS.

[inopinatus]

Oh I see. He meant an implied "but provide an extra path for discovery as well". I read the old proposal. It is flawed as you say and in several other ways besides. Perhaps we are in vehement agreement? In any case, this is the issue ticket giving consideration to proper use of DNS by Persona.

I have to leave off now, it's late here ...

[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!