>The point is not to allow larger policy bodies but rather to leverage existing >authentication of HTTPS server certificates. We want some form of >authentication for two reasons: > >1. We want it to be relatively hard to induce a DoS (as discussed in "Security >Considerations"); requiring a policy to be authenticated helps mitigate that >risk slightly. (Otherwise we're creating a variant of the >inject-a-bad-MX-record DoS but with a really >long TTL!) > >2. More importantly, we want to allow recipient domains to update a policy on >demand, outside of expirations, so that they can signal a new MX is trusted >(and similar). > >The authentication mechanism need not be HTTPs, and in fact when I started >drafting this originally I suggested we just stick the policy + signature + >cert chain in a DNS record--but that implies big DNS records, and that people >figure out how to fetch >and validate them plus the whole cert chain, and >ultimately, using HTTPS just seemed a lot easier and well-understood than that. > >Hopefully that makes sense, but I will note that there are some slight >relevancies for the parallel thread going on about SAN vs MX host >matching--namely that the motivator for HTTPS (to leverage well-understood >existing protocols) is also an argument >for host matching, as Alberto has >pointed out. > >Dan
First of all, thank you for the quick answer. And I hope you don't mind sending my thoughts to the list. Regarding the policy validation, would't the use of DNSSEC fix both the validation and update on demand problem? The TTL would allow you to control how often the DNS record needs to be refreshed, and the max_age could tell the client MTAs how often to fetch the policy. I guess it is a question of what is more complex? deploying DNSSEC or adding an HTTPS service. I hope I am not getting too much out of topic, asking about DNSSEC. In the SAN vs MX discussion, if I'm not wrong, the discussion is either to use the mx parameter from the policy to filter MX hostnames, or to use it to filter against the SAN within the certificate received. Since the section 4.2 (https://tools.ietf.org/html/draft-ietf-uta-mta-sts-03#section-4.2) defines that "... presented by the receiving MX MUST be valid for the MX hostname and chain to a root CA that is trusted by the sending MTA ...", the result of any of the two options would be the same (we assume that an attacker cannot forge a certificate that would pass certificate validation). But, using the mx parameter to filter the MX records, would create somehow an alternative way of discovering the list of MX for a domain, why would I fetch the MX records from the DNS, if I know that the valid list is in the mx parameter of the MTA-STS policy? Therefore I think that using the mx parameter to filter against the SAN list would be a better option. Finally, about the use of JSON or pairs of values to describe the policy, I think that if the use of JSON has to be an added complication for implementing the MTA-STS, it is better to use pairs of values. So far the policy is not that complex. The JSON format can be added in future versions when the policy description become more complex. Gerard Draper Gil
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
