4 ms·
It seems that this kind of weakness in tenant isolation is something that's hard to avoid in a public cloud environment, yet really critical to get right, to pr
by g_p 6y ago
It seems that this kind of weakness in tenant isolation is something that's hard to avoid in a public cloud environment, yet really critical to get right, to preserve confidence in it.
Yet given the nature of SPF and DMARC, they're inherently going to be pretty open to other tenants in the absence of IP-based isolation.
Perhaps each tenant could use a unique outbound IPv6 in future (if it reaches traction on servers), and have a small pool of such personal IPv6s allocated exclusively for their own email, across the other fallback systems?
DKIM is better as it uses cryptographic keys, but you need to give a cloud email host be access to these, or realistically load its own DKIM key into your DNS.
Any other ideas on ways to stop these kinds of cross tenant issues when designing cloud services? I'm assuming nobody will provision infrastructure per tenant due to scale and cost, but this is quite a serious issue underlining the risk of relying on a tenant account with public cloud providers when it comes to isolation.
- ascar 6y agoDMARC is essentially the combination of SPF and DKIM, so it's a bit misleading that you are mentioning SPF and DMARC and make it sound like DKIM is something separate. See Wikipedia [1]. If I recall correctly, DKIM setup is simply publishing the public key as a txt DNS record under your domain. Whoever has the fitting private key can then sign emails on your behalf. The cloud email host can without problem generate a new pair for every domain. So the "upload it's own DKIM key" is essentially creating a pair for you and telling you to set the public key as a certain DNS text entry. Pretty straightforward. Stopping the cloud provider to sign emails for you is also as simple as removing the DNS entry from your domain. > I'm assuming nobody will provision infrastructure per tenant due to scale and cost Actually, these services are available at a premium. [1] https://en.m.wikipedia.org/wiki/DMARC https://en.m.wikipedia.org/wiki/DMARC
- georgyo 6y agoDMARC is only policy, it is not SPF or DKIM. You can have any combination of DMARC, DKIM, and SPF. They are all distinct. Though with DKIM there is no way for a receiver to know if a message should be signed unless there is also a DMARC policy. SPF on the other hand can be verified without DMARC at all. If Gmail.com had a DMARC policy that required a correct dkim signature, then the attack would have been much harder. Also, to be clear, gmail.com DOES have a DMARC and SPF policy and does not have or use DKIM.
- uhoh-itsmaciek 6y ago>If Gmail.com had a DMARC policy that required a correct dkim signature, then the attack would have been much harder. Can you have a policy like that? I was under the impression that DMARC passes if either SPF or DKIM passes.
- LeonM 6y ago> Can you have a policy like that? No you cannot, like you said: DMARC passes if either SPF or DKIM passes. But what you can do is use the 'aspf' and 'adkim' settings to force strict alignment on SPF and/or DKIM for DMARC to pass. We see some of our [0] customers using strict SPF alignment to basically force DMARC SPF alignment to fail most of the time, thus effectively forcing a DKIM requirement for DMARC to pass. We wouldn't recommend doing this though, unless you are already closely monitoring your email traffic, and getting close to 100% DMARC alignment. Note that none of this would have helped against the vulnerability discovered in the OP though. [0] https://www.mailhardener.com https://www.mailhardener.com
- garaetjjte 6y ago>Though with DKIM there is no way for a receiver to know if a message should be signed unless there is also a DMARC policy. As a trivia, there was also ADSP but it didn't really gained adoption: https://tools.ietf.org/html/rfc5617 https://tools.ietf.org/html/rfc5617