On Sun, May 10, 2015 at 10:37 AM, Murray S. Kucherawy <[email protected]> wrote:
> That is, for a registration scheme, you might be testing for the existence > of a DNS record called A._related._dmarc.B. For a re-signing scheme, > you're looking for a signature from A that is somehow endorsed (for some > definition thereof) by a signature from B. The beauty of that mechanism is > that the signer gets to decide when to apply that endorsement, and with > what parameters. In fact, it's possible that A doesn't even know that B is > doing it. B could do it for all messages, which is simpler but increases > exposure; it could decide to apply the aforementioned heuristics and only > include the endorsement when it feels it's appropriate, which is safer but > requires a lot more internal infrastructure to support. Both camps are > enabled. > Sorry, I sent that too quickly. A couple of other points: In both schemes, you need a "registry", which is the set A as maintained by B through whatever means B wishes. Any DNS mechanism, however, requires that all mail flows from B via A are endorsed for as long as that DNS record is published (or cached); with the re-signing scheme, B gets to choose which specific messages carry that endorsement, via whatever logic it cares to apply, and for how long the endorsements are effective, and with what cryptographic strength and other parameters. We have evidence in hand that the queryable registry solutions are not attractive, evidence in the form of ATPS (RFC6541) for which the adoption rate was above zero by only a vanishingly small amount despite three years of open publication and an open source implementation. Despite other claims, there has never been evidence shown of interoperability of ATPS. The posting at the top of this thread makes such a claim, but it describes a single pre-RFC implementation interoperating with itself, rather than distinct implementations interoperating together; it is the latter that we tend to consider probative in IETF work. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
