[Changing Subject: to a new thread and dropping [email protected], since this is not charter discussion]
On Sun, Jul 20, 2014 at 12:27 AM, Douglas Otis <[email protected]> wrote: > ATPS is not the "lite version" of TPA-Label. This is explained in > http://tools.ietf.org/id/draft-otis-tpa-label-04.html#rfc.appendix.C > I disagree. I think that's exactly what it has turned out to be. ATPS requires DKIM signatures used by Third-Party Services to somehow > determine different label encoding methods permitted by ATPS. ATPS also > lacks any discovery or exchange method for this. In contrast, TPA-Label > makes NO demands on third-Party services. None. Since there is only one > encoding method, there is NO guesswork discovering the listing encoding > method. > There's no magic involved here ("somehow"? really?). The third-party selects a hash algorithm, or opts not to use one, and indicates this choice in the generated signature. The possible choices are enumerated in the specification. The verifier thus knows which hash (if any) was used. There is no discovery or exchange needed, since any DKIM implementation already includes support for all of the ones that ATPS specifies. Claiming there's some kind of burden ATPS has that TPA-Label does not have is simply false. If this truly is a burden (which I seriously doubt), selecting one hash or the "none" option and removing the other choices from ATPS is certainly possible, but first I think I'd like to see some evidence that this is a pain point either for implementers or operators, or that it creates an interoperability problem. The extra processing is only done when DMARC indicates non-complaince where > the DMARC domain can then indicate whether they have informally federated > the domain in question and what if any additional information must be > included in the message. In comparison, processing a new DKIM-ike > signature involves greater overhead than that needed to obtain a TPA-Label > resource which happens only after the domain in question has been > validated. It seems TPA-Label represents far easier deployment and far > less overhead since the Third-Party makes no change to their process and > only a single, small, cacheable TPA-Label resource is provided by the DMARC > domain. > Both methods start from a place of non-compliance of the basic case, namely non-authentication by the author domain. ATPS requires that the third-party have signed with DKIM (and thus as we say, "taken some responsibility for") the message under evaluation; TPA-Label does not have this constraint by default, which means TPA-Label is cheaper to deploy. However, I'm at a loss to understand why "X is an approved third-party for Y" is meaningful when neither of those identifiers are authenticated. If Y is a high-value target, then an attacker can merely claim to be X; without authentication, TPA-Label still approves this. "Just make X authenticate with DKIM," you say? Guess what, you're back to ATPS. All of the other options TPA-Label has about must have this header field or that one, or the value of this field must align with that one, are trivially satisfied by an attacker because the acceptance policy is made public, and I don't think they add any protection that isn't thus trivially defeated. They may help for a migration, for example, but not as an effective security mechanism against a bad actor. In terms of what's useful to DMARC, the ability to announce a third-party delegation approved by the author domain and authenticated by SPF is the only thing ATPS can't already do. And I'm not convinced that either of these methods is better than the ephemeral delegation idea. Anyway, all of that is for the working group to decide. Finally, Appendix C of the TPA-Label draft makes what I believe is a bogus claim about causes for the lack of ATPS adoption. The reason is far more general: Even though we made ATPS available for free, including deployment tools, there has never been any obvious evidence that a third-party mechanism is sufficiently secure, scalable, and above all, necessary. It is the main reason why TPA-Label, which is older than ATPS, has also seen no adoption to speak of. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
