Glen Wiley writes: > In light of all of the discussion about how the LHS of email > addresses are normalized and encoded/hashed in order to be used to > publish certificates and keys via DANE records like SMIMEA and > OPENPGPKEY we have put together an approach that lets a zone owner > signal the policy that is used for their domain by adding a few > keywords to the DMARC record.
This makes no sense to me. DMARC by design expresses policies centralized in the administrative domain (AD) for email, and it efficiently centralizes implementation in the MTA. On the other hand, draft-ietf-dane-openpgpkey-07 clearly states that it will be used to distributes keys (plural!) linked to individual email addresses. I see no reason why the "typical" organization won't choose to have equally individualized policies, especially in light of the fact that DMARC and its lower-level components of DKIM and SPF already cover the generic aspect of AD policy (though they don't mention encryption). draft-ietf-dane-smime-09 refers to this possibility indirectly by mentioning that the "trust anchor" might usefully be wild-carded -- which implies that in some cases it would not be, ie, it would be individualized. On the other hand, draft-ietf-dane-openpgpkey-07 acknowledges that "It is unclear if this RRtype will scale to some of the larger email service deployments." Given the success of DMARC in reducing the effect if not the quantity of malicious mail, as a mail admin I would be dubious about linking an experimental protocol which could potentially involve a large burden on my DNS to DMARC. I don't see any way for anybody on the Internet to use DNSSEC for traditional operations, but opt out of DANE extensions here. I think it should be added if you're going to have AD-level policy discovery: you should be able to say "we sign our A records but please don't ask us for PGP keys". One thing that worries me is that individuals or departments smaller than an AD may choose to PGP sign and distribute keys by one of the already established channels. The protocol values "required", "optional", "forbidden" are not expressive enough for this, unless there is coordination between the AD and the smaller units, and you proliferate subdomains and corresponding _dmarc subdomains merely to express policy. AIUI avoiding that proliferation and making the _dmarc result cacheable for whole ADs is considered an advantage of the DMARC scheme. As far as I can see the main advantage of this proposal vs. having a separate _dane_name_policy subdomain is that you can register the new tags in the DMARC registry rather than establish a separate one. Are there any advantages to DMARC participating sites that don't want to participate in DANE? I imagine that if the dane-openpgpkey and dane-smime proposals were widely implemented, with policy records to match, information about mail flows that disregard those policies and those that respect them would be of value for reasons similar to the value of information about DMARC alignment. Have you given any consideration to integration of reports of that information with the existing DMARC reporting? _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
