On Thu, Apr 17, 2014 at 7:51 AM, Vlatko Salaj <[email protected]>wrote:
> making DMARC strictly based on OR-logic will get it obsolete as soon as > someone finds a way to exploit any of the underlying mechanism, and that's > already possible, either through DKIM replay attack, or through spoofed SPF > authentication, whichever serves an attacker better. > The DKIM replay attack assumes that either (a) the entire content is signed, in which case the only replay is the re-sending of a complete original (which is presumably valid), or (b) there's partial content signing going on, which is strongly discouraged practice anyway. What's an example of spoofed SPF authentication? > "I do not want alignment" is exactly the same as "I don't use DMARC" > > since DMARC is pretty much all about alignment. So, again, I don't > > understand why that's a useful thing to add. > > it's not the same. DMARC is not just authentication, it's also about > reporting > and conformance. i would be perfectly happy to get my email checked against > SPF and DKIM and processed in a standard-defined way, and receive reports > on > which i can then act. otherwise, DMARC has no benefits for me at all. > So you don't want the authentication enforcement, only the reports? Isn't that what "p=none" does? You would get reports of unaligned mail and SPF/DKIM results in that case already. > >> and it's a common practice, absolutely. whether it's formal or informal. > > What's an example? > > i've already written about it. someone using yahoo or google email service > to send their own domain email. i actually do that. and i imagine, a great > deal of ppl. > > it also covers various 3rd party services, such as ones that deliver > greeting > cards, process petitions... > It seems to me more like you're talking about a way to extend specific other domains to be allowed to send mail as your domain and still pass. SPF and DKIM already have mechanisms to do that, not to mention experimental extensions like ATPS. The problem is that you need to know ahead of time which senders will do so, which has the obvious scaling problem. Of course, since DMARC is about keeping control over that, maybe it's an expected scaling problem, but it's still something that needs to be handled. >> as i said: combined, alignment OFF and AND processing logic would work > great > >> in cases where alignment isn't possible, yet email is fully legitimate. > > For the "off" case, isn't that just the same as "p=none"? > > it isn't. if we accept the idea about making alignment optional, i would > gladly expand the idea to more than just turning alignment on/off. > I still don't understand this. What's the difference between "p=none" and what you're calling "alignment off"? > actually, such alignment field would, in my proposal, include a > three-state: > > 1. alignment ON, in which case from: header gets checked against. > > 2. alignment OFF, in which case domain owner specifies they have no benefit > from DMARC alignment checks, but do want other checks performed, such as > AND-logic mechanism evaluation, for example. > But the AND-logic is "SPF and DKIM have to pass, and be aligned". So you're saying both need to pass (in the AND case), but it doesn't matter which domains they validated? Again, that means I can send any mail I want as your domain and that would pass DMARC, and I'm not clear about why you want that. 3. alignment domain-list value to include in alignment check: list of > domains > the domain owner wants to have included in DMARC alignment check, > complementing > from: header domain; this will cover almost all cases DMARC breaks now, > such > as 3rd party infrastructure, mailing lists that do not wish to make changes > for DMARC-compatibility, forwarders that process their mail, but can't be > controlled by domain owner, etc. it's somewhat similar to SPF domain > definition, > but different, since it affects DMARC-alignment process. > Right, that's the third-party case discussed above. There are a bunch of limitations, assuming this is something that's actually in enough demand to add. For starters: (1) sticking the list in a DNS TXT field will not scale (suppose you want to authorize a thousand third parties), and (2) you have to keep the list current, which will need automation and security around it as users seek to add entries (by subscribing to lists, for example). > I totally agree there, especially since Sender-ID got almost no adoption > > (see RFC 6686), and that seems unlikely to change now. > > it would change quite fast if we would make it part of DMARC. > What would be the value in doing so? > PRA could actually be a better way to determine owner's domain for > alignment > purposes than some undefined public-suffix list, especially in the light of > newest moves by ICANN, introducing bunch of new top-lvl domains, which will > probably host a bunch of sub-domains with registration capabilities by 3rd > parties, etc. > I don't think we really want to re-have the MARID arguments. The fact that in several years nobody adopted Sender-ID speaks pretty loudly to me. > DMARC's dependance on a concept of "public-suffix list" is a can of worms > i can't wait to see what will make of DMARC's usability at the end. it > will be > a mess for sure. i'm not rly sure how this isn't obvious to DMARC's > authors, > given all that experience in the domain. > It is obvious. Appendix A.6 even acknowledges that the public suffix method is "far from perfect", and that if and when any better mechanism appears, DMARC should change to use it. There has been work appearing in the IETF's Applications Area to create such a system, but there's nothing formal or deployed yet. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
