Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Hector Santos <[e-mail]>]

On 4/26/2023 11:51 AM, Scott Kitterman wrote:
> I agree that more will be needed.  Thanks for the feedback.  The last run at this question ended up being a mess, so I'm trying to see if we can get further by going in small steps.
>

Scott,

I  provided some suggested text below of what I think, as an 
implementator,  to get closer to finishing this DKIM Policy project.

Incremental changes is always preferred, but it has been many years 
with operational experiences. We know where the stepping stones are.  
That was the goal with ADSP as well and unfortunately the stepping 
stones are being ignored.  So lets not ignore them anymore to we can 
move forward with a more protocol complete DKIM Policy model.

The beauty of the IETF RFC documentation format is that its addresses 
a wide audience of disciplines  It's a blend of all the functional, 
technical, security and operator's manual.  But the RFC is for 
everyone, including management and decision makers.   I think the 
wording for the I-D can be done to satisfy all.

Look it at this another way. We really don't have a problem anymore. 
We know what the mitigations are.  So whatever is done with the I-D, 
the problems as been addressed.   So I suppose, its more of a clean 
up, a codification of what has happened with the DKIM Policy model 
that now comes under the umbrella of DMARC.  We know what the issues 
are and the solutions.  Why not just document this and be done.

Proposed new Appendix A section.

    A.8  Mailing List Servers

    Mailing List Servers (MLS) applications who are compliant with
    DMARC operations, SHOULD adhere  to the following guidelines to
    integrated DMARC.

    Subscription and Submission Controls

        MLS subscription processes should perform a DMARC check to
        determine if a subscribing or submission email  domain DMARC
        policy is restrictive in regards to mail integrity changes or
        3rd party signatures. The MLS SHOULD only allow subscriptions
        and submission from original domain policies who allow 3rd
        party signatures with p=none policy.


    Message Content Integrity Change

        List Servers which will alter the message content SHOULD only
        do so for original domains with optional DKIM signing
        practices. If the List Server is not going to alter the
        message, it SHOULD NOT remove the signature, if present.


    Security Tear Down

        The MLS SHOULD NOT change the author's security by changing
        the authorship address (From) domain.  It should apply
        subscription/submission controls.  However, if there
        circumstances where a From rewrite is necessary, ideally, a
        rewrite with a new address SHOULD may the same level of
        security as the original submission to avoid potential Replay
        and Display Name Attacks.


Proposed updated 4.4.3 section.

     4.4.3. Alignment and Extension Technologies

    DMARC can be extended to include the use of authentication and
    authorization mechanisms that assist in DMARC evaluation of policy.

    Any new authentication extensions will need to allow for domain
    identifier extraction so that alignment with the RFC5322.From
    domain can be verified.

    Authorization extensions deal with the condition when the author
    domain does not match the signer domain.  These are called 3rd
    party signatures.  The following Author::Signer domain
    authorization methods has been explored:

        DomainKeys Identified Mail (DKIM) Authorized Third-Party
        Signatures (ATPS)
        [https://datatracker.ietf.org/doc/html/rfc6541]

        Third-Party Authorization Label  (TPA)
        [https://datatracker.ietf.org/doc/html/draft-otis-tpa-label-08]

        Mandatory Tags for DKIM Signatures
        [https://datatracker.ietf.org/doc/html/draft-levine-dkim-conditional-04]

        Delegating DKIM Signing Authority
        [https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-delegate-02]

    The first two are DNS-based and the latter are non-DNS-based. All
    have one goal - To authorize the 3rd party signature.

    The ATPS proposal is the simplest method and it has shown success
    in practice to reduce false positive failure results when a valid
    and unverified but ATPS authorized 3rd party signer is present in
    a message.  MDA receivers should consider using ATPS to verify 3rd
    party signatures.


I hope this can be a starting point for someone better than me can 
write for the RFC wide audience.

I personally feel, we should have an ATPS section that shows the 
simple steps with the "atps=y" tag added to the DMARC record, the 
discovery method and how publishers can delegate 3rd party signers 
using ATPS records.

The key is to get closer towards completing the DKIM-based secured 
mail system with 3rd party signer support as it was originally 
envisioned.

Thanks

-- 
Hector Santos,
https://santronics.com
https://winserver.com