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

["Murray S. Kucherawy" <[e-mail]>]

[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 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