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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
