Hi, I was wondering what the rationale is for adding the mts-sts prefix to the domain where the policy file is loaded? E.g. https://mts-sts.example.com/.w ell-known/mts-sts.txt
As a security feature, an attacker: - must be able to add a .well-known/mta-sts.txt file in a specific format (or maybe redirect). Adding a .well-known URL is supposed to be difficult. - must be able to spoof a special TXT record, either by controlling the network (MITM without DNSSEC) or controlling the DNS itself (e.g. cache poisoning) - must be able to add a subdomain (otherwise the prefix doesn't have a security advantage) and possibly issue a certificate for it While there is certainly a security advantage with the third requirement, I wonder how big it is? Being able to add a .well-known file *and* tampering with the DNS sound like two very different abilities for an attacker. A MITM can already easily block the initial DNS request for the TXT record but once MTA-STS takes effect it can only block policy retrieval, not change the policy itself (unless it can tamper with the HTTPS request in which case there is a bigger problem). In fact, blocking policy retrieval gets *easier* when the domain is prefixed with mta-sts, as it can simply drop the DNS request itself. It would be a lot harder to block a HTTPS request on the bare domain without blocking the website itself. But maybe I've missed something - I'm not a security expert. I also think it may be easier to set up MTA-STS on a host if the mta-sts prefix is removed. It drops the requirement for a new subdomain and certificate. This could help adoption of the standard. -- Ayke
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
