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

[Douglas Foster <[e-mail]>]

Hector, does your proposal allow for constrained delegation?   I think we
have a problem if this type of third-party signing allows any account at
the list domain to impersonate any account in any participating domain.

DF

On Sat, Apr 8, 2023, 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
>