Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)
On Fri 18/Sep/2020 15:17:53 +0200 Joseph Brennan wrote: or don't use p=quarantine and p=rejectKeep it simple Publishing an actionable policy is not just a question of simplicity. It conditions the very semantics of DMARC. OTOH, MLM transformations break signatures irrespective of From: rewriting. Perhaps, we should make it more clear whether the "MLM problem" consists of the inconvenience of having From: rewritten rather than the inability of verifying the original author domain signature. At any rate, the two drafts referenced below propose methods to validate the original domain. At that point, the original From: can safely be restored. Considering that both methods have to rely on additional stuff passed in the message header, the two methods can be viewed as strikingly similar to each other. Best Ale On Fri, Sep 18, 2020 at 5:47 AM Alessandro Vesely wrote: On Thu 17/Sep/2020 21:11:42 +0200 Sabahattin Gucukoglu wrote: Wouldn’t it be nice if you could ask for MLMs to transform, just using a DMARC policy, even p=none, so that you could test with a live environment containing MLMs that work around DMARC policy? Or you could ask for *no* transform, even for p=quarantine or p=reject, so that your DMARC policy can be used to legitimately restrict usage to directly-sent email? It may be practical to place the asking in the message header, rather than in the DMARC record. That way, senders can specify their wish on a per-message basis, presumably based on message recipients. Note that a request to transform can include information about how to reliably undo the transformation, thereby verifying the original DKIM signature as described in dkim-transform[*]. Possible strategies that senders might use could be similar to those for putting weak signatures[†]. Best Ale -- [*] https://tools.ietf.org/html/draft-kucherawy-dkim-transform [†] https://tools.ietf.org/html/draft-levine-dkim-conditional-04#section-4.1 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)
or don't use p=quarantine and p=rejectKeep it simple On Fri, Sep 18, 2020 at 5:47 AM Alessandro Vesely wrote: > On Thu 17/Sep/2020 21:11:42 +0200 Sabahattin Gucukoglu wrote: > > > > Wouldn’t it be nice if you could ask for MLMs to transform, just using a > DMARC policy, even p=none, so that you could test with a live environment > containing MLMs that work around DMARC policy? Or you could ask for *no* > transform, even for p=quarantine or p=reject, so that your DMARC policy can > be used to legitimately restrict usage to directly-sent email? > > > It may be practical to place the asking in the message header, rather than > in the DMARC record. That way, senders can specify their wish on a > per-message basis, presumably based on message recipients. Note that a > request to transform can include information about how to reliably undo the > transformation, thereby verifying the original DKIM signature as described > in dkim-transform[*]. Possible strategies that senders might use could be > similar to those for putting weak signatures[†]. > > > Best > Ale > -- > [*] https://tools.ietf.org/html/draft-kucherawy-dkim-transform > [†] > https://tools.ietf.org/html/draft-levine-dkim-conditional-04#section-4.1 > > > > > > > > > > > > > > > > > > > > > > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)
On Thu 17/Sep/2020 21:11:42 +0200 Sabahattin Gucukoglu wrote: > > Wouldn’t it be nice if you could ask for MLMs to transform, just using a > DMARC policy, even p=none, so that you could test with a live environment > containing MLMs that work around DMARC policy? Or you could ask for *no* > transform, even for p=quarantine or p=reject, so that your DMARC policy can > be used to legitimately restrict usage to directly-sent email? It may be practical to place the asking in the message header, rather than in the DMARC record. That way, senders can specify their wish on a per-message basis, presumably based on message recipients. Note that a request to transform can include information about how to reliably undo the transformation, thereby verifying the original DKIM signature as described in dkim-transform[*]. Possible strategies that senders might use could be similar to those for putting weak signatures[†]. Best Ale -- [*] https://tools.ietf.org/html/draft-kucherawy-dkim-transform [†] https://tools.ietf.org/html/draft-levine-dkim-conditional-04#section-4.1 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)
I had been working on proposed language to strengthen section 5, which has a very weak justification of the use of the From address, because the prior discussion has left the issue hanging.The current text is followed by my proposed replacement text. Perhaps the group and the chairs are ready to address issue 73? Doug Foster Current language: 5. Use of RFC5322.From One of the most obvious points of security scrutiny for DMARC is the choice to focus on an identifier, namely the RFC5322.From address, which is part of a body of data that has been trivially forged throughout the history of email. Several points suggest that it is the most correct and safest thing to do in this context: * Of all the identifiers that are part of the message itself, this is the only one guaranteed to be present. * It seems the best choice of an identifier on which to focus, as most MUAs display some or all of the contents of that field in a manner strongly suggesting those data as reflective of the true originator of the message. The absence of a single, properly formed RFC5322.From field renders the message invalid. Handling of such a message is outside of the scope of this specification. Since the sorts of mail typically protected by DMARC participants tend to only have single Authors, DMARC participants generally operate under a slightly restricted profile of RFC5322 with respect to the expected syntax of this field. See Section 6.6 for details. Proposed 5. Use of RFC5322.From DMARC's use of the RFC5322.From address has been challenged as arbitrary, especially since many MUAs display it only upon request.However, the RFC5322.From has consistently been understood to represent the person or other entity who is the author of the content and for whom responsibility should be attributed, so the integrity of RFC5322.From is critical to the credibility of the content. If the content is to be reliably attributed, the FC5322.From address needs to be reliably verified. Only the RFC5322.From address can serve this purpose. The RFC5322.From has all of the necessary characteristics for the purpose of attribution. First, it is a globally unique identifier. Secondly, it is stable over time. Because it is unique, it distinguishes this author from all other authors with similar names. Additionally, because many users have multiple email addresses for different purposes, the RFC5322.From address also distinguishes between different roles taken by a single individual. For all of these reasons, it is very useful for searching and sorting. The RFC5322.From address is the only identifier that is presented to the user which can be verified. The RFC5322.From address is the value which the user expects will be used for replies to the message. A successful spoof of the RFC5322.From address permits the attacker to "put words in the mouth" of the spoofed individual, an action which could cause great harm to the sender's reputation. If the recipient of the spoof replies to the spoofed originator, the recipient might also suffer significant embarrassment. By comparison, the Friendly Name provides no uniqueness, has no settled format, has no verifiability, and has no permanence.Since the Friendly Name is usually configured in the MUA, the Friendly Name may change randomly based on the MUA currently being used by the sender, and the sender can alter it at any time to any value for any reason. Attackers have been known to mimic the Friendly Name of someone known to the recipient to increase the effectiveness of the attack. When a user sees suspicious content from a trusted Friendly Name, one appropriate response is to compare the Friendly Name to the RFC5322.From address to test for logical consistency. Often, this is sufficient to detect the deception. The value of the RFC5322.From address has been established by two disparate groups: users of mailing lists and criminal actors. Neither of these groups can be considered supporters of DMARC. Mailing list users have complained vigorously because DMARC enforcement has caused mailing lists to alter the RFC5322.From address in ways that make sorting, searching, and other actions more problematic for them.Criminal actors have responded to DMARC by using look-alike domains that seek to impersonate the identity of a well-known domain without being subject to DMARC controls. This action demonstrates that the criminal subculture, which DMARC seeks to restrict, knows that a successful spoof of the RFC5322.From address will be beneficial to their efforts. From: listsebby=40me@dmarc.ietf.org Sent: 9/17/20 6:10 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not) On 17 Sep 2020, at 20:59, Jesse Thompson wrote: > On 9/17/20 2:11 PM, Sabahattin Gucukoglu wrote: >> Wouldn't it be nice if you
Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)
On 9/17/20 5:09 PM, Sabahattin Gucukoglu wrote: > On 17 Sep 2020, at 20:59, Jesse Thompson > wrote: >> On 9/17/20 2:11 PM, Sabahattin Gucukoglu wrote: >>> Wouldn’t it be nice if you could ask for MLMs to transform, just using a >>> DMARC policy, even p=none, >> >> It is possible via p=quarantine pct=0. >> >> I think it makes sense to consider codifying beyond this defacto standard >> hack. Isn't this part of DMARCbis? It was discussed, anyway. Which ones >> are active? https://trac.ietf.org/trac/dmarc/report/1 > > These tickets seem to be relevant: > #22 (Perverse incentives to use p!=none & pct=0): > https://trac.ietf.org/trac/dmarc/ticket/22 > #73 (Need decision on importance of From domain): > https://trac.ietf.org/trac/dmarc/ticket/73 > #63 (Make p=none with no reporting URI invalid—Closed): > https://trac.ietf.org/trac/dmarc/ticket/63 > > I did not realise that this “hack” had become widespread. I agree that it > should be codified, or else p=none explicitly needs to support it (and in > that case reporting must remain optional). I can’t speak to the pct > parameter, because my sites are too small to really benefit from it. I can't say how widespread it is in practice, but the concept has been discussed occasionally in various contexts. Those of us who choose to [mis]deploy DMARC for user domains may find it useful. The tactic was helpful to identify some of the DMARC-unaware MLMs in use. ... I don't want to overlook your other idea about advertising the ask for *no* transform. Is the idea that the domain owner can decide when they feel like there is adequate adoption of ARC, and a suitable reputation system, so that the intermediaries aren't saddled with that uncertainty into eternity? On one hand, I worry that domain owners will never actually know that ARC is ready until they actually ask intermediaries to stop transforming (and observe what breaks). On the other hand, it puts control for ARC adoption into the hands of the community. It also gives us something to measure ARC adoption in a more meaningful way. Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)
On 17 Sep 2020, at 20:59, Jesse Thompson wrote: > On 9/17/20 2:11 PM, Sabahattin Gucukoglu wrote: >> Wouldn’t it be nice if you could ask for MLMs to transform, just using a >> DMARC policy, even p=none, > > It is possible via p=quarantine pct=0. > > I think it makes sense to consider codifying beyond this defacto standard > hack. Isn't this part of DMARCbis? It was discussed, anyway. Which ones > are active? https://trac.ietf.org/trac/dmarc/report/1 These tickets seem to be relevant: #22 (Perverse incentives to use p!=none & pct=0): https://trac.ietf.org/trac/dmarc/ticket/22 #73 (Need decision on importance of From domain): https://trac.ietf.org/trac/dmarc/ticket/73 #63 (Make p=none with no reporting URI invalid—Closed): https://trac.ietf.org/trac/dmarc/ticket/63 I did not realise that this “hack” had become widespread. I agree that it should be codified, or else p=none explicitly needs to support it (and in that case reporting must remain optional). I can’t speak to the pct parameter, because my sites are too small to really benefit from it. Cheers, Sabahattin ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)
On 9/17/20 2:11 PM, Sabahattin Gucukoglu wrote: > Wouldn’t it be nice if you could ask for MLMs to transform, just using a > DMARC policy, even p=none, It is possible via p=quarantine pct=0. I think it makes sense to consider codifying beyond this defacto standard hack. Isn't this part of DMARCbis? It was discussed, anyway. Which ones are active? https://trac.ietf.org/trac/dmarc/report/1 This trick also helps you find all of the receivers that ignore pct (treating your policy as p=quarantine pct=100) This was annoyingly unexpected for us, but it happened to be an accidental graceful rollout mechanism that, I feel, worked better than ramping up the pct as designed. Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)
AFAIK, at the moment, MLMs doing transforms on headers to make messages DMARC-safe have no reliable way of knowing whether sender domains intended them to do so or not: there’s a heuristic that just says that in general, a DMARC domain enforcing an active quarantine or reject policy probably wants transforms. Wouldn’t it be nice if you could ask for MLMs to transform, just using a DMARC policy, even p=none, so that you could test with a live environment containing MLMs that work around DMARC policy? Or you could ask for *no* transform, even for p=quarantine or p=reject, so that your DMARC policy can be used to legitimately restrict usage to directly-sent email? For me the first is more important: I could make the case for DMARC much more strongly if I could rely on MLMs to implement a reliable workaround, under sender control, so DMARC-sceptics could challenge themselves to the actual consequences of the policy, without their enforcement, or continue to support traditional forwarding and/or mailing lists as neutral actors while positively impacting DMARC-safe mail. Without the workarounds being guaranteed, the current state of play, there’s no DMARC-safe future that works for everybody, IMO. It’s reasonable to argue that these workarounds are horrible and I would. It’s also, unfortunately, everyday reality nowadays with two long-standing freemails using DMARC and all the major MLMs with support, and I have since been induced by practical experience to believe that, honestly, what matters for most MLM users is utility over functional purity. I have had at least one subscriber tell me that they _prefer_ the Mailman 2.16+ workaround because now they get the list name in the display name instead of the Subject making it easier to scan, and they can whitelist the list address to avoid the spam box or get notifications for list mail. I can’t even make myself care that Reply-to-all is broken—because that’s inevitably what people want for most lists, anyway. Heresy, I’m sure. :) I still think DMARC’s use of the From: header is its biggest failing. Far better would have been to take the high road and use a dedicated Authenticated-Sender: (or likewise) header. MUAs would change, to explicitly distinguish authorship from “sendership”. But we are where we are. I could not call myself a fan of DMARC; I just think it’s inevitable. Cheers, Sabahattin ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
