Re: [dmarc-ietf] ATPS, TPA-Label, etc.

[Douglas Otis <[e-mail]>]

Dear Murray,

Thank you for responding.  

See comments inline:

On Jul 20, 2014, at 3:55 PM, Murray S. Kucherawy <[e-mail]> wrote:

> [Changing Subject: to a new thread and dropping [e-mail], since this is not charter discussion]
> 
> On Sun, Jul 20, 2014 at 12:27 AM, Douglas Otis <[e-mail]> 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