RFC7672 2.2.2 "Secure CNAME" considered harmful?
I've been reading RFC7672, in particular the part about TLSA lookup for the "Secure CNAME" case. Not only can I not find a legitimate reason to attempt to obtain a TLSA record for the fully-resolved CNAME first; further, I've come up with a very plausible scenario where it's actively harmful and allows an untrusted party to seize control of the service.
Consider a service hosted on dynamic IP address. One way to do this without needing one's own dynamic DNS infrastructure is with CNAMES. If one owns example.com, one can make foo.example.com a CNAME pointing to a hostname on an existing dynamic DNS provider, e.g. example.dyn.com. Traditionally, prior to DNSSEC and DANE, this would have allowed dyn.com to hijack the service by redirecting the A record for example.dyn.com. However, if example.com is authenticated by DNSSEC and has a TLSA record pinning a particular key for foo.example.com, one would expect this hijacking no longer to be possible -- if dyn.com redirected example.dyn.com, they would not have the private key matching the TLSA record, and could not hijack any traffic from clients performing DANE validation.
However, RFC7672 section 2.2.2 specifically overrides this expectation for SMTP, and mandates that, if dyn.com is also authenticated, clients attempt to obtain a TLSA record for example.dyn.com and give it precedence over the one for foo.example.com. This reopens the possibility of hijacking, and seems outright wrong.
I believe it can be mitigated by someone aware of the problem, with a dummy intermediate insecure zone:
foo.example.com CNAME foo.dummy-insecure.example.com foo.dummy-insecure.example.com CNAME example.dyn.com
where dummy-insecure.example.com is a zone that's intentionally left unsigned, to break the chain of authenticated data.
But it seems unrealistic to expect people to know to do this, and error-prone since subtly non-conforming clients may misinterpret the broken chain of authenticated data as foo.example.com being insecure and not subject to DANE at all.
Can anything be done about this? Is there a reason for the existence of the "Secure CNAME" case that needs to be preserved, or is this something that could be pushed for deprecation?
On Thu, May 21, 2020 at 09:21:41PM -0400, Rich Felker wrote:
I've been reading RFC7672, in particular the part about TLSA lookup for the "Secure CNAME" case. Not only can I not find a legitimate reason to attempt to obtain a TLSA record for the fully-resolved CNAME first; further, I've come up with a very plausible scenario where it's actively harmful and allows an untrusted party to seize control of the service.
This is not the right forum for this topic. Likely dane@ietf.org may have been more appropriate.
1. In fact MX records are supposed to not be CNAMEs. So you should not, and generally would not operate the inbound MTA for a domain via a CNAME to dyn.com.
2. Despite the above, most MTAs do honour "CNAME-valued" MX records. And the majority of those cases, the CNAME points at an MX provider, not a DNS-resolution provider like dyn.
3. If your IP records CNAME into a zone managed by an untrusted party, they can make your A-records appear unsigned, and some implementations will not fall back to a CNAME query to check for DNSSEC in the MX host's zone. The fallback CNAME check is tricky, and I do not expect it to be consistently.
4. In most such cases, the CNAMEs in question are multiple names for the same MTA managed by its owner, or aliases to a provider managed mailserver. Not a mailserver for which just the IP record is outsourced to a third party.
In the actual cases in use, the users benefit from a single operator managing both the target IPs and the target TLSA records. They would otherwise have to be sure to publish additional CNAMEs from their TLSA qname to the provider's TLSA RRset. This is extra work they're likely to neglect.
For example 472 domains alias MX hosts to mail.kingsquare.nl.
Bottom-line, my take is you're grasping at straws.
I believe it can be mitigated by someone aware of the problem, with a dummy intermediate insecure zone:
foo.example.com CNAME foo.dummy-insecure.example.com foo.dummy-insecure.example.com CNAME example.dyn.comwhere dummy-insecure.example.com is a zone that's intentionally left unsigned, to break the chain of authenticated data.
Yes, though as I mentioned, this can also break DANE, and nobody is going to do this...
But it seems unrealistic to expect people to know to do this,
We're on the same page here.
Can anything be done about this? Is there a reason for the existence of the "Secure CNAME" case that needs to be preserved, or is this something that could be pushed for deprecation?
Wrong forum, and we disagree.
On Thu, May 21, 2020 at 11:09:39PM -0400, Viktor Dukhovni wrote:
On Thu, May 21, 2020 at 09:21:41PM -0400, Rich Felker wrote:
I've been reading RFC7672, in particular the part about TLSA lookup for the "Secure CNAME" case. Not only can I not find a legitimate reason to attempt to obtain a TLSA record for the fully-resolved CNAME first; further, I've come up with a very plausible scenario where it's actively harmful and allows an untrusted party to seize control of the service.
This is not the right forum for this topic. Likely dane@ietf.org may have been more appropriate.
In fact MX records are supposed to not be CNAMEs. So you should not, and generally would not operate the inbound MTA for a domain via a CNAME to dyn.com.
Despite the above, most MTAs do honour "CNAME-valued" MX records. And the majority of those cases, the CNAME points at an MX provider, not a DNS-resolution provider like dyn.
If your IP records CNAME into a zone managed by an untrusted party, they can make your A-records appear unsigned, and some implementations will not fall back to a CNAME query to check for DNSSEC in the MX host's zone. The fallback CNAME check is tricky, and I do not expect it to be consistently.
Indeed, that's a really good point. This flakiness of client implementation probably makes such a setup a non-starter.
In most such cases, the CNAMEs in question are multiple names for the same MTA managed by its owner, or aliases to a provider managed mailserver. Not a mailserver for which just the IP record is outsourced to a third party.
In the actual cases in use, the users benefit from a single operator managing both the target IPs and the target TLSA records. They would otherwise have to be sure to publish additional CNAMEs from their TLSA qname to the provider's TLSA RRset. This is extra work they're likely to neglect.
For example 472 domains alias MX hosts to mail.kingsquare.nl.
This would still work with the opposite priority order: TLSA for the domain named in the MX taking precedence, with fallback to TLSA for the fully-resolved CNAME if there is no TLSA record for the former and the full CNAME chain is authenticated.
Bottom-line, my take is you're grasping at straws.
I don't see how that's an apt description of a question about a possible flaw in the security design.
Can anything be done about this? Is there a reason for the existence of the "Secure CNAME" case that needs to be preserved, or is this something that could be pushed for deprecation?
Wrong forum, and we disagree.
Can you point me to a description of what is on-topic here? Even if this is not the right forum to make change, it seems like a reasonable forum to gauge opinion on the topic from people actually using DANE with SMTP and determine if or how approaching it in another forum (IETF) might be appropriate.
Rich
On Thu, May 21, 2020 at 11:31:32PM -0400, Rich Felker wrote:
For example 472 domains alias MX hosts to mail.kingsquare.nl.This would still work with the opposite priority order: TLSA for the domain named in the MX taking precedence, with fallback to TLSA for the fully-resolved CNAME if there is no TLSA record for the former and the full CNAME chain is authenticated.
That could have been a possibility, as indeed would requiring the domain owner to actively provision a CNAME from _25._tcp.<cname-owner> to _25._tcp.<cname-target>.
I optimized for two considerations:
1. Ease of deployment. If your MX host provider (possibly after CNAME resolution) has TLSA records, you're done.
2. Alignment of operational responsibility. Whoever is operating the MX host is best positioned to keep correct TLSA RRs in place.
This meant preferring the TLSA RRs as close as possible to the actual MX host domain. Now you have a corner case where the MX host is really in the origin domain, and only its IP address resolution is delegated.
I must admit this was not considered at the time, but that I am considering it, I am not especially fond of the idea of switching the order of precedence.
What I can say is that TLSA RRs after CNAME indirection are not terribly common, and we could (at the cost of not supporting DANE for a small fraction of users) drop the CNAME chasing, not because of the dyn.com situation, but simply because it is complex, and perhaps not worth the cost.
Can you point me to a description of what is on-topic here? Even if this is not the right forum to make change, it seems like a reasonable forum to gauge opinion on the topic from people actually using DANE with SMTP and determine if or how approaching it in another forum (IETF) might be appropriate.
This is a very quiet list, mostly just my monthly posts, but occasionally some operational topics. Not much standards discussion here. It'd probably be just you and me, and we could do that off-list.
I could be misjuding who's here of course...
participants (2)
-
Rich Felker -
Viktor Dukhovni