It's been a while since I looked at the drafts, and they're looking good. The area I'm getting stuck on is max_age. It's a point of user-configurability, with little guidance on what's good, and the strong possibility that people will make weak or otherwise bad choices.
As someone who expects MTA-STS to have a similar effect to HSTS - effectively ratchet security, it seems like it's desirable for it to be as long as possible. In general, the fact the a complete failure causes a policy update makes this simple and safe. There are a couple of reasons why I think it's not quite that easy: 1. It's not desirable for a 'report' configuration to be used beyond the point that a domain has switched to 'enforce', and a long-cached 'report' policy could do this. 2. It prevents new MX records (eg new servers for increased capacity or backups) not covered by the cached policy from being used until the max_age, or until a failure to send with all the covered servers. There is also a downside that if policies are cached for a long time, misconfiguration of the policy server is less likely to be noticed quickly as fewer domains will be sending reports indicating a failure. Having pondered it a bit, my suggestion is: 1. A SHOULD that max_age is set to at least 6 months, other than during roll-out 2. A SHOULD that well-behaved clients with a cached policy should re-check DNS TXT policy weekly, and retrieve via HTTPS if the policy id has changed. An alternative to (2) would be to add an optional refresh_after field with similar semantics which would have a default value of 7 days which could be overridden if, for some reason there are concerns that weekly is too often (but I'm generally of the opinion that fewer options are better). I hope that makes sense, and do let me know if I've missed something. Cheers, David On Wed, Feb 15, 2017 at 7:57 PM, Brotman, Alexander < [email protected]> wrote: > Folks, > > We uploaded new revisions for MTA-STS and TLSRPT. There are minor changes > to each: > > 1) Remove the "_" from DNS records to be consistent with A/AAAA records > used with the HTTPS retrieval, and make this a bit less confusing for > deployments. We did this for both MTA-STS and TLSRPT. > 2) Clarify language around punycode > > Please give these a review and get back to us with any comments. Thank > you. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse > Comcast > x5364 > > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
