> On May 10, 2015, at 2:00 PM, Murray S. Kucherawy <superu...@gmail.com> wrote: > >> On Sun, May 10, 2015 at 10:37 AM, Murray S. Kucherawy <superu...@gmail.com> >> 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.
First, ATPS was hampered by the fact ADSP was being demoted. Second, RFC6541 raised the barrier by extended it off the DKIM signature. We were already tired of more changes to DKIM, we did not need more. Instant barrier to adoption. Third, ATPS was an experiment and the author was included stuff, "it won't work anyway". It can't do that. Doesn't help the technical marketing. It doesn't. So yes. It was poorly proposed in my opinion, but it was understandable given the focus to use thrust rather than policy. But we can't compare the situation because now you have interest in a "Super-ADSP" [sic], which mean the 3rd party hook off DMARC should of be the proper integrated step. FInally. It is running code between different operators and the IETF take it into account. Which means I can send mail to a list, expected it to be resigned and my own system and others can do the lookup for the resigner authorization. You forget that a system can support it for authorization but does not itself need or can publish records. In all, all your points and my points should be part the interoperating report but I totally disagree it is not an overall IETF technical protocol feasible solution. It will probably never be a feasible solution for the limited domains in question, no matter what is done. But that should not stop the protocol from being part of the DKIM policy layer. It didn't stop any other similar DNS application. Now, If we are trying to avoid the intense IETF DNS community review sure to follow, I can see a valid point, but avoiding it is just as bad. I suggest that a proper DNS lookup model is still the proper most feasible solution and that will be presented during review. At some point we need to stop the DKIM changes. You just made it a STD. Maybe we could probably retract that STD status with and addendum if it a going to continue to change. -- Hector Santos http://www.santronics.com
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
