Secure Delegation for Service Hosting Across Domains

Feature Requests
1

Let's imagine a service that uses the combination of localpart and domain as identifiers (e.g., user@example.com), similar to XMPP, email, and Matrix. An organization wants to use its own domain (example.com) for user identities, but delegate the actual hosting to a third-party provider.

Traditionally, this delegation is done using SRV records, such as:

_xmpp-client._tcp.example.com. ...
_xmpp-server._tcp.example.com. ...

_matrix._tcp.example.org. ...

However, this approach lacks a secure mechanism to link the identity domain (example.com) with the hosting provider’s infrastructure. Since DNS is not secure by default, an attacker could manipulate SRV record responses and perform a man-in-the-middle (MITM) attack, redirecting users to a malicious server.

Obtaining certificates for each customer domain is often not practical for hosting providers. It would typically require either access to the customer's web server (to place validation files) or control over their DNS (to insert validation records) -- neither of which is feasible or scalable.

This problem has been considered before. One proposed solution is described in RFC 7711, which involves placing a file in the .well-known directory of the domain to indicate delegation. Matrix, for example, supports delegation through either SRV records or files placed under .well-known. While this method can be secure against MITM attacks, it has notable drawbacks: any vulnerability in the domain’s web server (e.g., via a compromised CMS) could allow an attacker to modify the .well-known file and silently redirect clients to a malicious server—intercepting credentials and communication.

At present, there appears to be no widely adopted, secure, and practical solution to this delegation problem that doesn't introduce new risks or infrastructure complexity.

Proposed Idea: Service-Specific Certificates

One possible solution could be the introduction of a new type of certificate—restricted to a specific service (e.g., XMPP, Matrix, etc.). This certificate would include a dedicated field indicating the service it is intended for.

Validation would work the following way:

  1. The client first resolves the SRV record for the service, retrieving the target domain of the hosting provider.
  2. The client then connects to the hosting provider's server and verifies that the presented certificate is valid and includes a trusted delegation assertion for the original domain and service.

This would leverage the existing certificate infrastructure, while allowing secure, service-specific delegation without needing control over the customer's web server or DNS.

2

Let's Encrypt and ACME do not use SRV records for delegation (uses NS or CNAME).

But, I think you would find the below thread helpful. I linked to post #21 by Aaron Gable so you can see comment from an LE staff person. The entire thread is full of informed and useful info by other volunteers so I recommend that after reading Aaron's post to start at the top

3 Likes
3

I was referring to how clients for protocols like XMPP locate their servers. In those cases, SRV records are typically used to map the identity domain (like example.com) to the hosting provider’s infrastructure.

4

Maybe it's me, but what is your proposal fixing exactly? Which issue?

Because for unsecure DNS there's already DNSSEC, DNS over HTTPS, DNS over TLS et c.

2 Likes
5

I'm confused. This is exactly what the vast majority of managed service providers who offer custom domain integration for web services actually do today.

Is the difference here that what the hosting provider is trying to secure is not a typical web service?

3 Likes
6

If authenticated DNS was widely available, CAs wouldn’t be that necessary. We could publish certificate hashes in DNS records, similar to DANE, letting clients verify them directly.

However, DNSSEC adoption remains low (Cloudflare, SIDN), with many TLDs and registrars still not supporting it.

As for DoH and DoT, they’re supported by OSes, but require manual configuration. An app could use a built-in resolver, but then the user would need to accept the ToS and privacy policy of that hardcoded resolver. This would delegate full trust over authentication to that resolver, which is a separate problem.

7

Let’s say a corporation wants to use the same domain (example.com) for web hosting, email, XMPP, and Matrix, each hosted by a different provider. That’s entirely possible -- SRV records (and MX records for email) exist for exactly this purpose. For instance, the A record could point to the web host, MX (and possibly IMAP SRV) records to the mail host, XMPP SRV records to the XMPP provider, Matrix SRV or well-known delegation to the Matrix provider, and so on.

The challenge is that there’s no straightforward way to secure this setup, because only the web hosting provider can obtain a certificate for example.com.

9

I think that @petercooperjr summarized the issue well:

There are two possibilities here:

  1. The client expects a certificate for example.com. If some-other-host.example.net is third-party hosted, that brings the practical challenges of obtaining such a certificate that I described in my initial post.

  2. The client expects a certificate for some-other-host.example.net. In this case, a MITM attack could simply redirect the client to evil.com, and it would connect without complaint.

Also, there was no further comment from @aarongable in that thread.

10

Let’s take email as an example. Suppose the example.com domain has an MX record pointing to example.net. If you want to use STARTTLS, which domain should you expect to see in the server’s certificate when you connect?

11

Actually, there is already an RFC with a very similar idea: RFC 4985 - Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name

12

I think the most common setup would be for the certificate to be for example.net. The only "spec" I know of is RFC 7817, section 3, which (if I'm reading right, and I may not be) says the client can validate against either or both. In a lot of cases email servers don't care about identity nearly as much as one might expect, and many accept a connection regardless of names presented in the certificate, unless DANE or MTA-STS are being used (which present their own requirements).

I think that what you're really asking for is something like the certificates containing "SRV-ID" names defined in RFC 9525 (which as you just mentioned but I somehow didn't notice until after I wrote this up, would use the id-on-dnsSRV subjectAltName entry defined in RFC 4985). Right now, I'm not aware of any public CAs working with those kinds of certificates, since their focus is mainly on HTTPS (and some email) use cases. While securing XMPP and SIP and other protocols is certainly important, I don't think as many people are working on it, and I doubt Let's Encrypt will want to spend their limited resources on trying to standardize and define validation methods for it (though I certainly could be wrong). And I know a lot less about these things than many other people; I am far from being an RFC or Public PKI expert.

5 Likes
13

Yes, exactly. I just hadn’t realized there was already an RFC covering it.

Let’s Encrypt has had a tremendous impact on securing HTTPS, but the internet runs on more than just HTTP. It would be great if other protocols could also benefit from easily accessible certificates. With their recent announcement supporting IP address certificates, I’m hopeful SRV certificates might be possible too.

14

I certainly agree it's an admirable goal and would be nice. I'm just pragmatically realizing that Let's Encrypt is a small operation and just can't do everything. It might be helpful if there were a group of people (maybe XMPP/Matrix/SIP server operators, I guess) working on a private PKI (and maybe not just for trying to secure the server end, but also for related client auth use cases), to battle-test what's involved in proper validation and creating these certificates for these use cases as well as in getting client software to recognize these SRV-ID names. If there are working solutions with a private PKI, then I think it's more likely that it could get integrated into the broader public Web PKI.

4 Likes
15

Isn't a chunk of the above handled by RFC 7712 - Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP) and RFC 7590 - Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) ?

1 Like
16

Which method would you recommend using? The second RFC just points to other ones that I will quote:

We rely on DNSSEC to secure SRV records that map the desired
service, transport protocol, and service domain to the
corresponding target server connection endpoints (i.e., the target
server host names and port numbers returned in the SRV records for
that service type).

Sadly DNSSEC support is still rare as I mentioned previously.

From 3.2

  1. The parties attempt TLS negotiation, during which the XMPP server
    (acting as a TLS server) presents a PKIX certificate proving that
    it is a.example.

That basically means sending the hosting provider your TLS certificate and key. This won't work when certificate lifetimes will be shorter and is very impractical.

Section 6 just basically states and explains the problem and points to other documents:

That one requires placing a file in the .well-known directory of the web root (https://example.com/.well-known/posh/example.json).

This is the most practical solution, but has a significant drawback. With a typical LAMP (Linux, Apache, MySQL, PHP) setup on the web server, finding a vulnerability in the website CMS would allow the attacker to modify that file and impersonate the server potentially without anybody noticing.

17

Okay, I had a minute (and some coffee) to fully read the above exchange. I apologize for my confusion above. When skimming things I focused on some examples you gave (which have obvious issues) and not what your intent is.

I agree that it would be wonderful to have a protocol and CA support around SRV record mechanisms - where the same FQDN is proxied to multiple hosts - however I don't think this is fundamentally possible or worth pursing under the current web PKI ecosystem.

I'm going to go through a few of the relevant issues with your examples, and then surface what my core concern here is –

This is true, but the same can apply to DNS-01 validation through TXT/CNAME records and HTTP-01/TLS-ALPN-01 validation. This is why ISRG has been investing heavily in multi-perspective validation - both in resources and research (including Let’s Encrypt Continues Partnership with Princeton to Bolster Internet Security - Let's Encrypt); and helped lead the push for it to become a CA/B standard.

The _acme-challenge TXT record can be CNAME'd onto the hosting provider, alongside the CNAME/A Record for the domain name.

I agree this is not currently easily possible, and understand this is what you want to accomplish.

While not ideal, this could be automated by giving each 3rd party service provider credentials to a secondary DNS system the _acme-challenge records are proxied onto. It would make more sense to me, however, for the hosting providers to offer an authenticated API and corresponding Certbot plugin to upload certificates with as they are procured. (Certbot covers a majority of installs, and can be used as a reference implementation).

A (barely thought out) potential change to the ACME protocol to facilitate this, might be supporting semi-configurable _acme-challenge DNS records. For example, instead of just having the default _acme-challenge label, one might have _acme-challenge-{EXTENSION}. This could allow _acme-challenge-foo to CNAME onto a specific hosting provider that is not what _acme-challege CNAMEs onto. As part of the ordering process, one would specify the {EXTENSION} used in the label. I am only sharing this as a thought exercise, because I would not want to see such a feature ever deployed. Why...

With all that being said, the fundamental issue I see with the core idea you've presented is this: the X509 standard does not include ports (or services) only domain names (and ip addresses). That means using SRV records to consolidate multiple providers under a single domain requires enabling each of the multiple service providers with an X509 certificate that can be used on any other service provider. I do not like that and find it incredibly dangerous – a random XMPP provider would have a certificate that could be used in a MITM attack for the core HTTPS service. This violates the widely adopted industry best-practice of sharding different service providers onto different FQDNs. Because X509 certs can not be limited to ports, I honestly don't think this is a worthwhile endeavor.

2 Likes
18

I think you're basically describing the draft proposed dns-account-01 challenge type.

And that's why I think there are standards for having SRV identifier in certificates, so that one could in theory use those instead of DNS (or IP) identifiers. Just client and WebPKI support isn't at the point of implementing all that yet.

5 Likes
19

GREAT catch! This is also at least the second time you have corrected me on something regarding that particular RFC!

I had actually thought of it for a split second, then dismissed it. But looking at the spec again you are absolutely correct, the draft-ietf-acme-dns-account-label-01 framework elegantly allows for multiple third party vendors to have dedicated _acme-challenge DNS labels.

Well, wow. I did not know about rfc4985 - which you referenced above.

So it looks like the only need would be to extend ACME (and the CA/B forum) to support rfc4985, and then leverage CNAMES onto third party hosting providers via draft-ietf-acme-dns-account-label-01. Does that sound right to you?

1 Like
20

For authenticating incoming server connections to other servers this problem was solved:

"lsec_ignore_purpose": Do not check the "purpose" flag (server/client) of the certificate.

This approach won't work with multiple providers - you can only CNAME _acme-challenge to one destination, so if you're using Provider A for XMPP and Provider B for SIP/Email/Matrix/other services, you'd need to constantly shift the CNAME between providers for each certificate renewal.

21

That's why I suggested delegating to a secondary DNS and allowing the providers to share the credential as an interim solution, and potential long term solution being multiple acme challenge records (though I oppose doing that for security concerns). @petercooperjr then noted the draft-ietf-acme-dns-account-label-01 RFC handles this. It was designed to allow multi-region cloud systems to each have their own isolated DNS-01 challenge and avoid race conditions, but could be used by multiple third party service providers.

1 Like