3 ms·

> Isn't by design it must cache for the amount of time specified in the TXT file? So it has to be durable. Kind of. The max_age in the text file is the max t

by agwa 5y ago

> Isn't by design it must cache for the amount of time specified in the TXT file? So it has to be durable. Kind of. The max_age in the text file is the max time a cached policy should be used if a new policy can't be retrieved (e.g. it's being blocked by an attacker). If a new policy can be retrieved over HTTPS, it's totally OK to use it even if the max_age of the cached policy isn't up yet. Thus, tyingq's suggestion is reasonable. In fact, the RFC already tells mail servers to look for a new policy if just one MTA-STS failure occurs (https://datatracker.ietf.org/doc/html/rfc8461#section-5.1 https://datatracker.ietf.org/doc/html/rfc8461#section-5.1 step 3). The problem is that it checks for a new policy using the ID in the TXT record, which as explained in the blog post is unreliable.

pas 5y ago
Thanks for the detailed explanation. It seems silly to introduce that extra level of indirection when there's already a well-known URL to try to fetch a new version. Is there any rationale for this? Also if DNS is explicitly a not trusted component this seems to strictly lead to a less secure system :o (But I guess the designers did not want to "completely" override MX records just with yet another out of band magic.)
- agwa 5y ago
  > Is there any rationale for this? Do you mean for the TXT record? The rationale for that was performance. I don't know if this rationale was backed up by hard data or just a theoretical concern that HTTPS requests are more expensive than DNS requests. > Also if DNS is explicitly a not trusted component this seems to strictly lead to a less secure system The TXT record doesn't contain any security-sensitive information so it doesn't actually reduce security. The worst an attacker can do is block the retrieval of a new policy, but they could also accomplish this by removing the mta-sts A/AAAA record. Either way, the cached policy will be used until its max_age expires.
  - pas 5y ago
    > Do you mean for the TXT record? I mean that during the max_age time the MTA knows that the target MTA has/had a policy, so it could directly query that again instead of doing the DNS lookup. But probably the spec writers did not want to risk MTAs getting hammered with HTTPS requests on every failure. > Either way, the cached policy will be used until its max_age expires. Ah, thanks. I got confused by the DNS spoofing, but of course since the policy is protected by PKI TLS even if the attacker can redirect the MTA to evil.com/policy.txt the cert won't match, and the email recipient domain is already in the email to be delivered. (And if that can be spoofed, then the mail contents are also very likely accessible.)

by agwa 5y ago

pas 5y ago

Thanks for the detailed explanation. It seems silly to introduce that extra level of indirection when there's already a well-known URL to try to fetch a new version. Is there any rationale for this? Also if DNS is explicitly a not trusted component this seems to strictly lead to a less secure system :o (But I guess the designers did not want to "completely" override MX records just with yet another out of band magic.)

agwa 5y ago
> Is there any rationale for this? Do you mean for the TXT record? The rationale for that was performance. I don't know if this rationale was backed up by hard data or just a theoretical concern that HTTPS requests are more expensive than DNS requests. > Also if DNS is explicitly a not trusted component this seems to strictly lead to a less secure system The TXT record doesn't contain any security-sensitive information so it doesn't actually reduce security. The worst an attacker can do is block the retrieval of a new policy, but they could also accomplish this by removing the mta-sts A/AAAA record. Either way, the cached policy will be used until its max_age expires.
- pas 5y ago
  > Do you mean for the TXT record? I mean that during the max_age time the MTA knows that the target MTA has/had a policy, so it could directly query that again instead of doing the DNS lookup. But probably the spec writers did not want to risk MTAs getting hammered with HTTPS requests on every failure. > Either way, the cached policy will be used until its max_age expires. Ah, thanks. I got confused by the DNS spoofing, but of course since the policy is protected by PKI TLS even if the attacker can redirect the MTA to evil.com/policy.txt the cert won't match, and the email recipient domain is already in the email to be delivered. (And if that can be spoofed, then the mail contents are also very likely accessible.)