Re: [dmarc-ietf] DSAP "DKIM Sender Authorization Protocol" for DMARC

[Douglas Foster <[e-mail]>]

Hector, here is my take on the DSAP proposal.   I am not sold.

DSAP notable features
1) DSAP policy can be used to identify and block non-mail subdomains of
registered domains.

This might be useful when mail-sending domains use p=(none|quarantine).
The equivalent result can achieved with DMARC by setting an exact-match
policy of p=(none|quarantine) on mail-sending subdomains, and a policy of
sp=reject on the organizational domain.   I actually think this is
what domain owners should do, unless they are moving to sp=reject.

However, my theoretical analysis of the problem suggests that attackers
have no incentive to impersonate a non-mail subdomain when a valid
mail-sending subdomain is undefended, so there is little risk of a non-mail
subdomain being impersonated.

2) DSAP policy can be used to identify valid signatures from unauthorized
sources.
This feature becomes important if private key leakage is common, which I
doubt.   Feedback reports provide partial visibility into the usage of DKIM
scope IDs, which may lead to detection of a key leak.   Once detected, key
rollover is used to disable the leaked key.  Since I don't perceive leaked
keys to be a significant concern for my incoming mail, I would be inclined
to trust the valid signature rather than trusting the DSAP policy.

3) DSAP can be used to indicate that a message must be signed.
This seems equivalent to DMARC p=reject with SFP=no policy.

4) DMARC can be used to allow mailing lists and any corollaries to sign
in-place-of the originating domain.
This is capability without current equivalent, but it requires the list to
negotiate with all of the sending organizations to publish the
authorization, and then hope that the receiving organizations will honor
the signal.   In most mailing list scenarios, the sending and receiving
organizations are the same.   So this is essentially similar to negotiating
an incoming filter exception for mailing list traffic.    Jesse recently
mentioned replacing a mailing list with thousands of lists.    Negotiating
with the domain owners for all of those subscribers does not seem
feasible.   Even if attempted, a subset of those domain owners will say,
"Not on my watch!"

The scaling problem occurs when we ask how many unique mailing list domains
will need to be included within a single domain's authentication list.
 The design would need to be flipped to use DNS subkeys, so that the number
of entries was unlimited, but the lookup for any one re-signing domain
returned a single record.  The scaling problem is solvable for the
authorized domain list, but building that list is not feasible.


DF

On Sat, Apr 8, 2023 at 2:01 PM Hector Santos <hsantos=
[e-mail]> wrote:

> Summary:
>
> I would like to reintroduce the DSAP (DKIM Sender Authorization Protocol)
> as a DMARC extended tag extension -dsap. The original DSAP draft covered
> nine 1st vs 3rd party signature policies from a verifier viewpoint, which
> addressed boundary conditions for DKIM signatures. The reintroduction aims
> to address concerns regarding 3rd party resigners.
>
> Key changes proposed for DMARC integration:
>
> o Introduce -dsap tag for DSAP support, covering a complete range of
> possible policies.
>
> o Use -asl tag for inline list of authorized signer support.
>
> o Implement -atps tag for ATPS support.
>
> o Formalize the From rewrite logic with a -rewrite tag.
>
> o Introduce -target tag to assist mail forwarders with authorized
> redirection of exclusive policies.
>
> The proposal seeks to offer better integration with today's wide range of
> mail applications, building on the existing DMARC protocol and improving
> 3rd party authorization and reporting.
>
>
> Background:
>
> In 2006, I submitted an I-D DSAP “DKIM Sender Authorization Protocol” that
> covers the boundary conditions for 1st vs 3rd party signature
> expectations.  There are nine 1st vs 3rd party signature policies in DSAP
> from a verifier viewpoint:
>
> Original 1st Party Signature (OPS)
> Not expected (-)
> Expected (+)
> Optional (~)
>
> Third Party Signature (3PS)
> Not expected (-)
> Expected (+)
> Optional (~)
>
> Using these expectations, DSAP can cover most if not all possible Boundary
> Conditions for DKIM signatures.
>
> I would like to re-propose DSAP but this time as a DMARC extended tag
> extension `-dsap` as I believe it can address our concerns regarding 3rd
> party resigners.
>
> Here is the 2006 DSAP proposal I plan on updating to support DMARC and
> ATPS:
>
> https://datatracker.ietf.org/doc/html/draft-santos-dkim-dsap-00
>
> History:
>
> The DKIM Policy Model began with SSP “Sender Signature Practices/Policy.”
> This image illustrates the overall process:
>
>
> [image: SSP Overview]
>
> Many today do not realize the original DKIM included Signature Policy
> protocol called SSP.   It was spit into DKIM-BASE and DKIM-SSP to help
> speed up the process. DKIM was well defined but SSP was not.  SSP covered
> various signing scenarios, however, there were 3 policies missing which
> DSAP covered:
>
> [image: v3_slide0022_image050.gif (392×199)]
>
> The DMARC protocol offers an exclusive only policy with
> p=reject|quarantine. This would be a -dsa=OP+,3P- policy With DMARC p=none,
> no other policy possible in terms of expectation other than an unhandled
> failed exclusive policy.  So DMARC is very limited making it a very to
> integrate with today’s wide range of mail applications.
>
> DMARC also introduced two more takes that I would like use replaced with
> DMARC and ATPS.
>
> For Reporting, DSAP provides tags for failure reports. This is now
> well-defined with DMARC. [DSAP only considered failure reports].
>
> For 3rd party authorization, DSAP provided the -asl tag. The asl tag was
> an inline small domain list tag.  But it can also signify a check using
> ATPS for higher scale applications.
>
> Everything would be the same with DMARC and DMARCbis.   The change would
> be:
>
> -dsap tag for DSAP support for the complete range of possible policies.
>
> -asl for inline list of authorize signer support
>
> -atps for ATPS support
>
> I would also like to formalize the From rewrite logic with a tag:
>
> -rewrite
>
> Which tells a resigner it may rewrite the From under certain conditions.
>
> -target is a new tag to help mail forwarders.
>
> DMARC has considerations for SPF results with a strong alignment
> requirement. One scenario where a -dsap=op+,3p- is with SPF hard failure
> during mail forwarding.   The -target will allow a forwarder to resign as a
> 3rd party without -asl or -atps requirements.
>
> —
> Hector Santos, CEO/CTO
> Santronics Software, Inc,
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>