Re: Suggestion: can we test DEMARC deployment with a mailing list?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?











[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]