The word "only" is doing a lot of heavy lifting in your sentence, but yes I think that's what this thread is requesting. Maybe subsumed in your "extend ACME and CA/B" is that it'd take a lot of effort to get CAs on board. And I don't see commercial CAs getting excited about something unless they could charge a lot for it. And non-profit CAs like Let's Encrypt have enough on their plates just trying to keep HTTPS going. All of which is why I was suggesting someone would need to put together some kind of private PKI at first, as a proof of concept. It's not like I personally have the time to work on that sort of thing.
3 Likes
Agreed. This would require a sizable effort to get the CA/B forum behind it. I think the major issue would be concerns over clients/libraries in the ecosystem correctly handling the the x509 extension in 4985. I was digging around to see if I could generate/test this, but the SRVName extension does not seem to be natively supported by any of the major Go or Python cryptography libraries (some have considered it in the past). It looks like several XMPP servers have been implementing their own certificate construction and parsing systems due to this. From a security perspective, I have major concerns over libraries not interpreting the SRV limitation properly - so clients would think a restricted certificate is a normal one.
@mimi89999 - Since SRV records are maintained in DNS, it makes little sense to me to involve or require a website as part of the challenge. I would focus on a DNS based challenge that somehow extends draft-ietf-acme-dns-account-label-01, as this would allow that draft to work with multiple third party service providers. Perhaps you can reach out to it's authors and see if they'd be interested in pushing for this with you?
Maybe something like:
- draft-ietf-acme-dns-account-label-01 would let you CNAME the relevant
_acme-challengelabel onto the provider's own DNS system - the provider would handle the entire challenge process on their DNS system
- you'd then a glue record to bind the SRV record on your DNS with the the third party account. Perhaps that is a TXT record that creates a hash of
{SRV RECORD}.{ACCOUNT URL}, similar to how draft-ietf-acme-dns-account-label-01 works.
1 Like
I was thinking about a more straightforward approach that would require no additional configuration.
I would introduce a new identifier type under the order object. Just like there is {"type": "dns", "value": "example.org"} and {"type": "ip", "value": "2001:db8::1"}, there would be {"type": "srv", "value": "_service._proto.example.com", "via": "example.net"}.
The value field must start with an underscore and represents the SRV record name to be queried. The via field is optional and contains the preferred target for performing verification. If via is not present, the CA can choose the target from any of the SRV records to perform validation.
The validation would proceed as if example.net was provided directly, and the resulting certificate will contain the SRV-ID _service._proto.example.com.
If a certificate only has SRV names in the Subject Alternate Names field, I wouldn't expect clients to treat it as a "normal" one with DNS names, it would be just like any other certificate that doesn't match the hostname that the client is expecting.
2 Likes
I agree.
Once upon a time, Search Engines gave good results. Today they're pretty bad, and often preface results with AI garbage.
Between the lack of native support for SRV in most major crypto libraries (alongside open tickets debating support for 5-10 years), misleading search results, and what appears to be completely incorrect AI results, I was led to believe the domain name would appear in the SAN and the SRV name would be used to restrict usage. Everything I wrote above was influenced by this fundamental misunderstanding.
2 Likes
I could draft an RFC for this, but would appreciate evaluation from someone more familiar with RFC processes and CA operations.
I wrote a draft RFC for that:
draft-mimi89999-srv-identifier-validation-extension-00.txt (9.0 KB)
I hope that maybe @jsha or somebody more familiar with the processes could look at it.
Feedback, in no particular order:
- It's confusing that the Problem Statement cites lack of dnssec deployment as an issue with the status quo, but then the Security Considerations point out that this document is still subject to DNS spoofing. If this document does nothing to improve the status quo with regards to DNS security, why discuss it at all at the top of the doc?
- The "existing approaches" section needs to discuss CNAME delegation of the _acme-challenge subdomain, which has allowed hosting providers to obtain certificates via dns-01 for domains whose DNS they don't control for years now. It should also discuss dns-account-01, which allows CNAME delegation to multiple different providers. As discussed up-thread, dns-account-01 solves all of the validation problems you're trying to solve; it just doesn't solve the "but now three different services all have certs for example.com, what prevents them from misusing them?" problem which is solved by id-on-dnsSrv.
- I don't like the "via" parameter. This is like if http-01 validation could specify which of the IP addresses resolved from A/AAAA records should be used for validation. It's an attack vector which allows someone who compromises just a single host to reliably succeed at validation every time, rather than needing to compromise every host.
- RFC 4985 says that dnsSrv SANs never contain a protocol component, i.e. they look like
_xmpp.example.com, not_xmpp._tls.example.com. This document contains no discussion of how the server should transform the identifier provided in the newOrder request in order to produce the dnsSrv SAN. - Are there any protocols which rely on certificates containing dnsSrv SANs today? If yes, how do they use them? Do they expect them to be accompanied by other kinds of SANs in the same cert?
6 Likes
Hello. Thank you for the detailed feedback and quick response!
This explains why the status quo of potentially checking the server certificate for the domain in the SRV target is unacceptable from a security perspective. It also clarifies why solutions like DANE, mentioned earlier in this thread, cannot be used.
While this document doesn't improve DNS security itself, it still provides value: performing attacks on server-to-server connections (especially with multi-point validation) is significantly more difficult than modifying DNS responses on a public WiFi network or simply setting up malicious open WiFi networks for that purpose. Additionally, the service-specific scope limits the blast radius compared to current solutions that result in overly broad certificates.
I'll add a discussion of CNAME delegation to the existing approaches section. Since dns-account-01 is still a draft, I wasn't sure whether to mention it. When I update the draft, I'll include it as it significantly changes my draft specification's positioning. The remaining value proposition is the certificate scope isolation you mentioned.
I understand the concern. However, having this parameter would significantly simplify operations. Consider a service provider that load-balances traffic between two hosts. Each host could independently request, deploy, and update certificates. Without the "via" parameter, there would need to be a mechanism ensuring both hosts present the same challenge. This adds complexity, and that complexity could itself introduce vulnerabilities.
I believe the security drawbacks of the "via" parameter are minimal. An attacker who compromises one host could already intercept a significant amount of traffic. They could also simply use the certificate and associated private key already present on the server.
I believe this represents an inconsistency in RFC 4985. The RFC states:
The content of the components of this name form MUST be consistent with the corresponding definition of these components in an SRV RR according to RFC 2782 [N3].
However, it doesn't specify how to ensure this consistency. The examples show _mail.example.com, which suggests omitting the protocol component.
Since the examples show:
Name Constraints
SRVName restriction Matching SRVName non-matching SRVName
=================== ================ ====================
_mail.example.com _mail.example.com _mail.1example.com
_mail.1.example.com _ntp.example.com
I believe it should be possible to simply omit the protocol part.
I doubt any protocols currently rely on them, since no publicly trusted CA issues such certificates. This creates a chicken-and-egg problem.
Generally, I believe that while compromise of a web host is significant, it shouldn't grant the attacker a certificate they can use to intercept traffic from other protocols and potentially intercept IM messages.
I reconsidered the dns-account-01 RFC and I don't think it will work for this use case. It would effectively prevent hosting providers from changing CAs since that would require every customer to update their DNS records, which isn't realistic.
Hosting providers need the flexibility to switch CAs easily when they hit rate limits, during outages, for pricing changes, or other operational reasons. This approach would remove that flexibility.
Something I forgot to note above: the DNS SRV record specifies a port for the service, but the X509 extension will only contain the DNS label. I would briefly acknowledge that in a spec.
2 Likes
Actually, the most popular Android XMPP client, a popular XMPP library and a very popular XMPP server support them! they are checking for "_xmpp-client." + domain
I've updated the RFC draft based on the feedback from this discussion: draft-mimi89999-srv-identifier-validation-extension-01.txt (10.4 KB)
Thank you all for taking the time to review my initial proposal and provide thoughtful feedback.
I've taken your feedback into consideration and believe the updated draft addresses the main concerns raised in this thread. The approach is now simpler and more aligned with existing standards.
@aarongable - I'd particularly appreciate your review of this revised version if you have time, given your detailed feedback on the initial draft.
I'd welcome any additional feedback from anyone on this revised approach.
I uploaded the draft to: draft-lebihan-srv-identifier-validation-extension-00 - Automated Certificate Management Environment (ACME) SRV Identifier Validation Extension
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.