My two cents.
1) What has changed since 2012 is DMARC, including the ability through DMARC to
obtain feedback. "New ATPS" would have to be implemented as a DMARC option,
not a new thing.
2) A lot of organizations seem to be stick at p=none. Maybe that means they
want it that way. Maybe it means that they are being courteous to mailing
lists. But maybe it means something about DMARC is too hard. I am assuming
that all of the problems with DMARC are related to third-party authorization,
and something needs to be done to make it easier.
3) Delegation with an ATPS-type email entry seems functionally equivalent to
DKIM scope delegation, with several benefits:
Easier and cheaper for the third-party to implement. The third-party only
needs to apply its own domain's signature. Simpler means quicker
implementation. Private keys are never exchanged.
Third-party is only responsible for its own key. A big organization like
Constant Contact or SendGrid could end up holding hundreds of thousands of DKIM
keys, and that becomes an attractive target for attackers. If a delegated DKIM
key store is stolen from a third party, the attacker knows every domain that
has been compromised. If an ATPS-delegated third party has a corporate DKIM
key stolen, the attacker knows that he has struck pay-dirt, but he does not
have an immediate enumeration of compromised organizations.. That enumeration
will require an additional data collection process, which might buy time for
the affected organizations to take evasive measures.
An ATPS-type scope delegation could be designated for a specific user, which I
assume will represents an application. ("SMTP address must be
applicationname@vendordomain"). This information is something that the
receiving system can enforce and report. It is a weak enforcement tool, but
limiting scope of delegation seems likely to satisfy some of the auditor
concerns associated with any third-party delegation. This is also a new ideas
relative to the original ATPS. Of course, a domain level delegation should
also be an option for situations that the authorizing domain deems appropriate.
("SMTP address must be *@vendordomain")
ATPS-type delegations could be given a pre-defined expire date (if specified
with that feature). This would be particularly appropriate where a third-party
authorization is linked to a time-limited contract. When the contract lapses,
the authorization lapses, unless both the contract and the DNS entry are
renewed. This limits risk associated with the possibility of
delegated-but-forgotten authorizations. DKIM delegations are always
good-til-cancelled (by removing the DNS public key).
Both DKIM and ATPS can be revoked easily, subject only to the limits of DNS
propagation.
DKIM delegation becomes impossible if the third-party is not cooperative.
ATPS-type delegation can be done unilaterally by the owning domain. I am
thinking of Proofpoint in particular. They violate my DMARC policy when my
users, who are non-clients, respond to a secure message from one of their
clients. Author self-copies arrive at my gateway looking like spoof, but I
can fix this with local policy. When my user uses reply-all to a message with
many recipients, those other domains will see my p=reject, which may mean that
messages are not delivered and my user does not know that it happened. Maybe
all those other domains will have a Proofpoint exception as well, impossible to
say. Maybe Proofpoint will begin header munging, but they have not done so
yet.
So the big benefit for DKIM is the i= clause, but I think the sender-limiting
potential with ATPS is superior to the impersonation-limiting capability of
DKIM. Besides, it seems generally agreed that i= has very limited use. On
all other risk-management concerns, an ATPS -type signature seems preferable.
Implementation obstacles and notes:
When a domain implements an ATPS signature, it must set the corresponding DMARC
policy to p=none. Otherwise, sites that are DMARC-aware but ATPS-blind will
block ATPS-authoized transactions. Consequently, this option will only
interest organizations that are currently at p=none or that have no DMARC
policy.
If a new feature such as ATPS is implemented, senders have a problem knowing
whether their recipients understand it or not. This dilemma would be helped
if recipients published a DNS token to indicate that they understand the new
feature. Some will consider this inappropriate information disclosure,
although I am currently having a hard time seeing the risk in the release of
that information. By and large, senders will want confidence that the new
feature is widely deployed before they will begin depending on it for outbound
delivery. In the absence of recipient reporting, change may never happen.
Doug Foster
----------------------------------------
From: "Murray S. Kucherawy" <[email protected]>
Sent: 8/19/20 2:38 PM
To: "Kurt Andersen (b)" <[email protected]>
Cc: "[email protected]" <[email protected]>, Alessandro Vesely <[email protected]>
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On Wed, Aug 19, 2020 at 10:11 AM Kurt Andersen (b) <[email protected]> wrote:
On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely <[email protected]> wrote:
On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote:
> The industry in general, and the IETF in particular, have chosen not
> to pursue widespread use of any kind of standards-based third party
> domain signature policy or reputation system. . .
> Both ATPS (individual submission, experimental, February 2012) and the
> REPUTE series of documents (working group, standards track, late 2013)
> saw nearly zero adoption after publication even when free reference
> implementations were provided. They differ from basic DKIM in that
> they require non-trivial upkeep, and that appears to be a step
> function inhibiting adoption among operators.
We can still try again. In particular, the non-trivial upkeep seems
to be a valid diagnosis.
Is there anything which has materially changed between 2012-13 and 2020 which
would indicate that the anticipated results for such effort would be any
different?
+1. If anyone has some kind of creativity in this space that they've been
hiding, now's the time.
-MSK
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
