Hi Fred,
We have already did all this. Over the last 9 years, we have produced
all these DKIM related documents:
RFC4686 Analysis of Threats Motivating DKIM
RFC4870 DomainKeys
RFC4871 DKIM (RFC5672.TXT, RFC6376.TXT)
RFC5016 Requirements for a DKIM Signing Practices Protocol
RFC5451 Message Header Field for Indicating Message
Authentication Status
RFC5518 Vouch By Reference
RFC5585 DKIM Service Overview
RFC5617 DKIM Author Domain Signing Practices (ADSP)
RFC5863 DKIM Development, Deployment, and Operations
RFC5965 An Extensible Format for Email Feedback Reports
RFC6376 DomainKeys Identified Mail (DKIM) Signatures
RFC6377 DomainKeys Identified Mail (DKIM) and Mailing Lists
RFC6541 DomainKeys Identified Mail (DKIM) Authorized Third-Party
Signatures
and that all doesn't include all the draft I-D produced by myself,
Doug Otis and others.
We are well pass the hypothetical, theory, proof of concepts, etc.
Mailing list Software with DKIM+POLICY support exists, at least ours does.
This is an issue of getting IETF endorsement to support the DKIM
POLICY framework. The IETF just made ADSP RFC5617 historic earlier
this year. DMARC snuck in with large domains enabling the strong
handing mode of operations. That surprised the IETF and left the
network not ready to handle this long known 9 year old DKIM+POLICY
design/change requirement situation. Other MLS software/operators
need to adjust and so far, the IETF is not willing to accept a
DKIM+POLICY framework the industry wishes to go with.
Overall, the two key changes are:
1) MLS checks/deny/notify new subscribers using restrictive policy
domains.
2) MLS checks/deny/notify new submissions from restrictive policy
domains list members.
Those two basic changes are needed in principle to honor the security
policy first.
The hard part was how to scale author domain authorized 3rd party
signers for author domain policies that allow resigning and this was
pretty much where it was all left at, with 3rd party authorization
proposals that piggy backed off the ADSP record with ATPS (RFC6541),
my ASL (Authorized Signer List) proposal and Doug's TPA proposal.
This is also where Levine's Whitelist suggestion can play a role, but
it still needs to be author domain authorized.
I don't see us going anywhere unless a fundamental IETF acceptance for
DKIM+POLICY occurs and that means honoring the security policy first,
not ignore it and continuing to forward unauthorized resigned mail.
Unless the ADSP status can be reversed, and DMARC is here to stay, the
IETF needs to update the DMARC document for 3rd party support.
Finally point, the example email attachment you had from
owen@xxxxxxxxxx, keep in mind it does not have a DMARC policy, but it
does a ADSP "dkim=all" which says that only the first party signer was
expected in all mail. But there is o reject/discard handling
semantics as it would be for a "dkim=discardable" ADSP policy.
--
HLS
On 5/2/2014 2:05 PM, Fred Baker (fred) wrote:
We have been having a fairly extended discussion, much of which seems hypothetical - �I don�t like DEMARC because I am worried that ... with mailing lists�. I wonder if we could take a moment to try it and see what happens?
As an example of the case that comes to mind, see attached. It is a message sent to v6ops@xxxxxxxx yesterday. The sender signed it using DKIM, the IETF changed the message (added some trailing text) before forwarding it, the receiver (e.g., Cisco IT) attempted to validate the DKIM signature - and failed.
It seems to me that we should not approve a procedure that has that effect, at least without some guidance for mail relay administrators. I could imagine two forms of guidance: �obey the end-to-end principle; don�t change the message the originator sent�, or �if you change a signed message, first validate the message you received and discard if that fails, change it, and then sign it yourself, so that a receiver can see who changed it and validate the outcome�.
Could we actually try such guidance in a sandbox, and document appropriate procedures for mailing lists?