> On Apr 3, 2017, at 5:23 AM, <[email protected]> > <[email protected]> wrote: > > Regarding the policy validation, would't the use of DNSSEC fix both the > validation and update on demand problem?
Quite so, but with DNSSEC you don't need STS, just use DANE. > 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. Yes, possibly renamed if ceases to be an MX hostname filter. > 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). That text would also change if the policy admits other matching names. > 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, No, it is an authenticated cached *filter* on the data obtained from DNS, and supports wildcards, which means that you don't actually get the MX hostnames from the policy. -- Viktor. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
