Hello UTA WG,
I'm writing to seek the working group's input on a security challenge
related to service delegation that affects protocols using SRV records
for service discovery.
The Delegation Challenge
Many organizations need to delegate specific services to third-party
providers while maintaining their domain identity. For example, a
company using example.com might want to:
Host their website on Provider A
Delegate email hosting to Provider B
Use Provider C for XMPP messaging
Delegate Matrix to Provider D
This allows organizations to leverage specialized providers for
different services while users continue to use identifiers like
[email protected] across all services.
Current Approach Using SRV Records
Service delegation is typically accomplished using DNS SRV records as
specified in RFC 2782. For example:
_xmpp-client._tcp.example.com. IN SRV 0 5 5222 hosting.example.net.
_matrix._tcp.example.com. IN SRV 0 5 8448 matrix-provider.example.
Clients discover these services by querying the SRV records and
connecting to the specified target hosts.
The Security Problem
Without DNSSEC (which has very limited deployment according to
Cloudflare and SIDN statistics), these SRV-based delegations are
vulnerable to DNS spoofing attacks. An attacker who can manipulate DNS
responses can redirect users to malicious servers, potentially
intercepting credentials and communications.
Why Providers Cannot Obtain Certificates for Customer Domains
For a hosting provider to obtain a certificate for example.com through
existing ACME validation methods, they would need either:
HTTP-01 validation: Access to the customer's web server to place
validation files at http://example.com/.well-known/acme-challenge/
DNS-01 validation: Control over the customer's DNS to insert TXT
records at _acme-challenge.example.com
Neither option is feasible or scalable in multi-tenant environments.
Customers typically don't want to grant their hosting providers access
to their web servers or full DNS control. Additionally, if multiple
providers need certificates for the same domain (web, email, XMPP,
etc.), only one can use the _acme-challenge CNAME at a time, making
concurrent validations impossible.
Existing Alternatives and Their Limitations
I've evaluated several approaches, each with significant drawbacks:
DANE (RFC 6698): Requires DNSSEC, which remains impractical due to
low adoption
POSH (RFC 7711): Places files in .well-known on the source domain's
web server, but any web server compromise (e.g., through a CMS
vulnerability) allows attackers to modify these files
dns-account-01 challenge: Ties validation to specific ACME account
URLs, preventing providers from switching CAs without requiring all
customers to update DNS records
Certificate sharing: Requires distributing private keys between
organizations, creating serious security and operational concerns
Proposed Solution: SRV-ID Certificates
I've drafted an ACME extension (available at
https://datatracker.ietf.org/doc/draft-lebihan-srv-identifier-validation-extension/)
that would enable validation and issuance of certificates containing
SRV-ID identifiers as defined in RFC 4985. This approach would:
Allow hosting providers to obtain service-specific certificates
(e.g., for _xmpp-client.example.com)
Limit the scope of certificates to specific services, preventing a
compromised XMPP provider from impersonating the organization's web services
Enable providers to obtain these certificates by having customers
add a single CNAME record pointing
_acme-challenge._myservice.example.com to the provider's DNS
infrastructure - a one-time setup that allows the provider to handle all
future certificate renewals independently
The validation would use DNS challenges placed at the service-specific
location (e.g., _acme-challenge._myservice.example.com), which customers
can CNAME to their providers once and forget about.
Questions for the WG
Are you aware of other solutions for secure service delegation that
don't require DNSSEC?
What are your thoughts on using SRV-ID certificates for this purpose?
Are there any security considerations I haven't addressed?
I believe this is an important gap in our current security
infrastructure that affects multiple protocols. This issue even impacts
email security and autoconfig mechanisms, as recently discussed on the
mailmaint WG:
https://mailarchive.ietf.org/arch/msg/mailmaint/sOyhyNtylX7eOlsQmA8WfuDH_Ss/
Thank you for your time and consideration. I look forward to your feedback.
Best regards,
Michel Le Bihan
_______________________________________________
Uta mailing list -- [email protected]
To unsubscribe send an email to [email protected]
