On 5/12/15 6:58 PM, Stephen J. Turnbull wrote: > Douglas Otis writes: > > > DMARC being unable to assert the domain > > I'm not sure what you mean by "assert the domain". AFAICS no new > protocol is needed to validate Sender -- SPF and DKIM allow that > already, and it's not obvious to me where the big threat is from a > misaligned or spoofed Sender. (A BCP might say that Sender should be > aligned with the SPF domain if available, and otherwise with a valid > DKIM signer otherwise). I suppose some receivers already use this > information in their reputational models. Dear Stephen,
Perhaps my intent was obscured by thoughts of what's next. Of course, nothing prevents DKIM/SPF alignment with the Sender header field. Restating: Ignoring the Sender header field is appropriate ONLY when just direct or transactional messages are issued by a domain. Only then are conflicts with RFC5322 avoided when asserting restrictive DMARC policy. Restrictive conflicts are due to the fact that DMARC lacks a means to assert the domain handles NORMAL email exchanges. In effect NORMAL messages will affect both DKIM and SMTP outbound registration alignment fields. Handling NORMAL email exchanges WILL cause policy requests based ONLY on From alignment to be UNRELIABLE and INCOMPATIBLE with RFC5322. Currently ALL DMARC policy assertions ignore the role of the Sender header field. DMARC wrongly assumed the domain would limit its email to only direct or transactional messages. When the Sender and the From header field differ, ONLY the Sender header field can be expected to establish domain alignments with SMTP outbound registration. UNTIL DMARC provides a provision to assert the handling of NORMAL email to permit conditional alignment with the Sender header field, no BCP can offer a solution. Conditional alignment might include the identifier likely being visible in the message or accompanied with an explicit DMARC authorization. A receiver can never reliably resolve a policy conflict caused by NORMAL email exchanges without input from the DMARC domain. Either SMTP needs to redefine roles for Sender and From header fields OR DMARC must include provisions to properly include the role of Sender. > > Many have not realized double signing is wide open to abuse > > Please present your threat analysis. As far as I can see, double > signing is no more vulnerable than the current practice for mailing > lists when relaying mail from p=none sites. It would increase the > attack surface for the kind of abuse that caused some major sites to > publish p=reject last April, but it's something that can be turned on > incrementally as a matter of local policy (just as DMARC itself was), > and it can be turned off as fast as you can propagate the config > change to your SMTP server farm (unlike p=reject itself, which suffers > from DNS caching lag). > > I wouldn't call that "wide open". Even assuming a new scheme might extend DKIM expiry carried within the DKIM signature to an authorized signature, this would be problematic since mailing-lists expect conversations to extend over fairly long periods. Authorized DKIM signatures via double signing sidesteps restrictive DMARC policy where a resulting message can be replayed to any number of recipients well beyond the control of the DMARC domain. This is a general feature of DKIM so no special analysis is necessary. The authorization is wide open since DKIM does not facilitate a means to squelch any resulting phishing campaign. How is double signing better than simply including the Sender header field? Acceptance can also be based on the Sender header field with an expectation greater effort is made to ensure the Sender identity: 1) is included in the message. 2) can be validated. Our practice was to ensure a response to abuse within 15 minutes using 5 minute TTLs. Consider the broken window theory. Being unable to respond in a timely and effective manner makes authorizations wide open. This lack of control will encourage higher levels of abuse. However, use of the Sender header field would ensure the sending entity is held accountable. Regards, Douglas Otis P.S. Sorry about the empty response I think was caused by a trackpad bump. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
