Trimmed to a few parts I have immediate comment/questions on: On Tue, Aug 9, 2016 at 9:08 PM, Viktor Dukhovni <[email protected]> wrote: > > Should this still apply when the names are DNSSEC validated? Or > should clients that obtain DNSSEC "secure" MX RRsets (or denial > of existence) skip the MX constraints in the STS policy, whose > primary purpose is to harden STS against DNS reply forgery? >
When would you want to do this but use STS instead of TLSA for the actual cert validation? Conceivably if your MX domain isn't your mail To domain and only the latter supports DNSSEC, I suppose. So I can see an argument for it. On the other hand, wouldn't a lot of senders have a stub resolver that doesn't know the validation status for DNSSEC (as the recursive resolver is the validating resolver)? In that case, how would this work? I guess if this is a MAY or a SHOULD that's still OK... > > The MTA-STS TXT record MUST specify the following fields: > > > > * id: (plain-text, required). A short string used to track policy > updates. This string MUST uniquely identify a given instance of a policy, > such that senders can determine when the policy has been updated by > comparing to the id of a previously seen policy, and must also match the > policy_id value of the distributed policy. > > A lenient parser SHOULD accept a policy file implementing a superset of > this specification, in which case unknown values SHALL be ignored. > > If both the published policy and the DNS record carry just one "id", then > changing these in concert becomes difficult. If the HTTPS resource is > updated first, then clients that see the new policy will constantly > refresh it via HTTPS because until the cached DNS record catches up. If > the DNS is updated first, similar > behaviour results. > > Furthermore, the statement that these "MUST" match is then wrong, the "id" > in the DNS policy is just a "refresh" signal, and the retrieved policy > would sometimes legitimately not match. > > Consequently, a better design is to publish multiple matching "id" values > in the HTTPS policy which can list a few recently published DNS "id" > values, in particular at least the current one published in the > authoritative DNS zone, and typically also the previous that may still be > present in some DNS caches. > > The recommended update process woud then be to update the HTTPS policy > "<id1>,<id2>" -> "<id2>,<id3>" and then update the DNS TXT record from > "<id2>" -> "<id3>". Clients that still have "<id2>" in their cached DNS > record would then accept the new policy as fresh since it still matches > "<id2>". > I notice that you and Stephen both caught this issue. We had been discussing it recently among the authors as well. Stephen's suggestion, in comparison: Why not fetch ".well-known/mta-sts/<id>" where <id> is > what I got from the TXT RR? I happen to favor this suggestion over the more complex one Viktor proposes above. I think not all of the co-authors agree, however. Any concerns (Viktor, or anyone else) with Stephen's suggestion? It seems like the smallest possible fix for this issue, and a very coherent one. Once the TXT update is out for >DNS TTL, of course, admins can remove the old JSON policy files to avoid a DNS MITM serving an old policy (for whatever gain). The primary counterargument here is, I think, the operational overhead of having to update the TXT on every policy update, but I think that's basically a given so long as we rely on DNS for the "there's a new policy!" signal. > > > To consider the policy as valid, the policy_id field in the policy MUST > match the id field in the DNS TXT record under _mta_sts. > > s/_mta_sts/_mta-sts/ Also update for multi-valued "id" in the policy. > Finally, no "MUST"s here, if the HTTPS id does not match the DNS, the > policy is still valid, but now the client will check for updates as > frequently as the client implementation allows since the DNS always seems > to indicate a requisite refresh. DNS is not authoritative here, and a > freshly retrieved and authenticated HTTPS policy holds regardless of any > "id" values in DNS. > I think you missed the point of the directive (which is fairly easy to do, because on rereading this sentence is worded completely incorrectly!). My point here was actually that a policy *once fetched MUST be applied to at least one message to one MX* before it is cached as valid. The reasoning here is to prevent caching and perma-DoS'ing someone who just serves up a totally broken policy. So we want to not only require the HTTPS fetch to succeed and the policy to fetch, but the policy to actually *work*. This is a higher burden on implementors (who must now cache the "success bit" per policy), but it seems worth it, I think. Thoughts? Dan
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
