Dear Murray, Thank you for responding.
See comments inline: On Jul 20, 2014, at 3:55 PM, Murray S. Kucherawy <superu...@gmail.com> wrote: > [Changing Subject: to a new thread and dropping i...@ietf.org, since this is > not charter discussion] > > On Sun, Jul 20, 2014 at 12:27 AM, Douglas Otis <doug.mtv...@gmail.com> 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 third-party service does not select the label hash algorithm as you seem to suggest. The Author's ADMD (also called just ADMD) will have independently published labels corresponding to various third-party services within the Author's ADMD's domain. Third-party services should not need to care about ATPS label encoding schemes. They should be allowed to carry-on with their normal verification methods without needing to discover and catalog a needless option. See http://tools.ietf.org/html/rfc6541#section-3 ,--- An authorized ATPS Signer makes a claim of this relationship via new tags in the DKIM signature, and the ADMD confirms this claim by publishing a specific TXT record in its DNS. '--- Requiring third-party services to change the process they use to allow recipients a means to validate their messages, which also requires discovering and cataloging label encodings used by each of the served Author Domains represents an unreasonable burden placed on third-party service providers. This is unreasonable because it offers no tangible benefit and needlessly changes and complicates third-party DKIM signature processing. The From domain is known. There is no need to introduce a new tag to clarify From domains. Secondly, by retaining a fixed hash, there is no reason to include a hash tag either. TPA-Label checks DMARC compliance only after the source of the message has been verified, at a minimum, as specified in the TPA-Label. Use of TPA-Labels is best done by adding a 'tpa' tag in the DMARC record for the From header field. A hash option represents a fairly significant federation deployment impediment. If a DMARC domain finds they are being DDoS by a particular third-party domain, they can publish a cacheable negative federation label to curtail most of the related traffic. TPA-Labels convey informal federations and carry no PII unlike SPF or DKIM. > The possible choices are enumerated in the specification. The verifier thus > knows which hash (if any) was used. What this again misses are needless changes that must be made by those offering (often free) third-party services. > There is no discovery or exchange needed, since any DKIM implementation > already includes support for all of the ones that ATPS specifies. This statement ignores what ATPS causes third-party service providers to face. Ideally, very few changes should be expected of third-party service providers. When there is a problem determined because DMARC is not being applied against messages they receive, TPA-Label provides a means to mitigate an abusive situation by requiring an OAR header field be added. > 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. There are several other changes TPA-Label has made as well. In the end, TPA-Label and ATPS represent significantly different approaches. For example, TPA-Label does not depend on the use of DKIM and therefore provides greater verification agility and closer compliance with that of DMARC. > 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. Cheaper yes; and no, TPA-Labels stipulate verification requirements for 'X' fully determined by the DMARC domain 'Y'. > 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. The 'Y' domain publishes TPA-Labels having a hashed label and optionally a string matching with 'X'. Publishing confirms 'Y' federations. > If Y is a high-value target, then an attacker can merely claim to be X; > without authentication, TPA-Label still approves this. No. TPA-Labels stipulate verification requirements for 'X' fully determined by the DMARC domain 'Y'. > "Just make X authenticate with DKIM," you say? Guess what, you're back to > ATPS. How can a service be federated that only verifies with DANE TLS or SPF? TPA-Label permits this mode of verification. ATPS can't and, as such, is not fully compatible with DMARC. > 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. As was stated in TPA-Label, confirming these header fields provide recipients a safer message sorting strategy. Messages lacking these headers in conjunction with the From header field sourced from a particular domain can be rejected and therefore never seen. The goal is to make the From header field more trustworthy and the required additional headers and their content should represent a harmless but potentially beneficial criteria. Why wait for abuse to occur? > 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. You have done great work, but you placed demands on those not likely to cooperate. In my view, a lack of response was more than understandable. Thank you for your feedback. It clarifies how we see this issue differently. My company would like to work with a large provider to prove TPA-Label operations at a large scale. There is still some work needed to define a federation request sent to the DMARC domain feedback. Regards, Douglas Otis
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
