Re: [dmarc-ietf] Weakening of enforcement concern
> On Apr 10, 2023, at 9:38 PM, Neil Anuskiewicz wrote: > > > >>> On Apr 10, 2023, at 9:24 PM, Scott Kitterman wrote: >>> >>> On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote: >>> I’m a bit concerned that the document will discourage domain owners from >>> working toward an enforcing policy. I’ve seen at least one person say that >>> most domains don’t need to go to p=reject. I’ve seen all sorts of domains >>> attacked? Granted, high profile domains or perceived lucrative targets will >>> receive the most attention but threat actors absolutely do attack all sorts >>> of organizations all the time. >>> >>> Maybe I’ve misunderstood but I hope that no langue that could be construed >>> as discouraging domain owners from moving toward an enforcing policy would >>> be a mistake. >> >> It all depends on the user base of the domain and the tradeoff between the >> benefits of having such a policy against the interoperability risks of >> having >> such a policy. >> >> We absolutely should be discouraging blind adoption of policies that result >> in >> reduced utility for email. For any domain that has non-transactional users, >> that takes work to assess the completeness of email authentication >> deployment, >> assess aggregate reporting to understand the likely effects of either >> p=quarantine or p=reject., and then evaluate the cost/benefit trade-offs >> associated with such policies. That's a non-trivial set of work to do and >> it's not cost effective for all domains to do it. >> >> Early in the deployment of SPF there was a similar push to deploy SPF >> records >> with -all (the SPF rough equivalent of p=reject). A lot of people did it >> without thinking it through and there were significant side effects. The >> community concluded that SPF Fail (due to the -all in the record matching) >> was >> not a sufficiently reliable indicator that mail should be rejected and >> largely >> stopped doing it. Scott, I’m also aware of what happened to SPF’s run as a policy layer. There’s a big difference between SPF and DMARC. People deploy DMARC with the knowledge that it is the policy layer. Many soon learn that SPF hard fail isn’t honored much. There were too many costs to enforcing with SPF. DMARC’s SPF OR DKIM makes for a more robust system that you can get your legit mail passing DMARC consistently. SPF does was it does well but it with things like forwarding breaking it, the presence of DKIM made up for some of SPF’s shortcomings and vice-a-versa. I think we can agree that SPF, in retrospect, wasn’t a good place to set policy. DMARC is a much stronger policy layer so I hope you are thinking that the policy setting aspect will go the way of SPF? It won’t. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weakening of enforcement concern
> On Apr 10, 2023, at 9:24 PM, Scott Kitterman wrote: > > On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote: >> I’m a bit concerned that the document will discourage domain owners from >> working toward an enforcing policy. I’ve seen at least one person say that >> most domains don’t need to go to p=reject. I’ve seen all sorts of domains >> attacked? Granted, high profile domains or perceived lucrative targets will >> receive the most attention but threat actors absolutely do attack all sorts >> of organizations all the time. >> >> Maybe I’ve misunderstood but I hope that no langue that could be construed >> as discouraging domain owners from moving toward an enforcing policy would >> be a mistake. > > It all depends on the user base of the domain and the tradeoff between the > benefits of having such a policy against the interoperability risks of having > such a policy. > > We absolutely should be discouraging blind adoption of policies that result > in > reduced utility for email. For any domain that has non-transactional users, > that takes work to assess the completeness of email authentication > deployment, > assess aggregate reporting to understand the likely effects of either > p=quarantine or p=reject., and then evaluate the cost/benefit trade-offs > associated with such policies. That's a non-trivial set of work to do and > it's not cost effective for all domains to do it. > > Early in the deployment of SPF there was a similar push to deploy SPF records > with -all (the SPF rough equivalent of p=reject). A lot of people did it > without thinking it through and there were significant side effects. The > community concluded that SPF Fail (due to the -all in the record matching) > was > not a sufficiently reliable indicator that mail should be rejected and > largely > stopped doing it. > > Aggressively pushing DMARC p=reject on domains that aren't ready for it may > well lead to a similar result. Let’s not. I’m not for aggressively advocation for p=reject. Before my current job I worked as a one person business with mostly small businesses. My contracts weren’t just about authentication but when it became clear that a company didn’t have the bandwidth to get to and maintain an enforcing policy, I didn’t push it. It likely would have done more harm than good. The document should make it clear that you have to know what you’re doing to get to an enforcing policy. So I’m not advocating boosterism for enforcing policies for everyone. But medium to large businesses I think should move toward an enforcing policy. We shouldn’t make it sound easy because it is not! Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weakening of enforcement concern
> On Apr 10, 2023, at 9:13 PM, Neil Anuskiewicz wrote: > > I’m a bit concerned that the document will discourage domain owners from > working toward an enforcing policy. I’ve seen at least one person say that > most domains don’t need to go to p=reject. I’ve seen all sorts of domains > attacked? Granted, high profile domains or perceived lucrative targets will > receive the most attention but threat actors absolutely do attack all sorts > of organizations all the time. > > Maybe I’ve misunderstood but I hope that no language that could be construed > as discouraging domain owners from moving toward an enforcing policy would be > added to the document. I meant to say that I’ve seen all sorts of domains attacked. The goal should be to get to an enforcing policy. It makes sense for very small businesses to be very reluctant to enforce unless they have the access to the expertise. But any domain owner that can should protect their domains. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weakening of enforcement concern
On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote: > I’m a bit concerned that the document will discourage domain owners from > working toward an enforcing policy. I’ve seen at least one person say that > most domains don’t need to go to p=reject. I’ve seen all sorts of domains > attacked? Granted, high profile domains or perceived lucrative targets will > receive the most attention but threat actors absolutely do attack all sorts > of organizations all the time. > > Maybe I’ve misunderstood but I hope that no langue that could be construed > as discouraging domain owners from moving toward an enforcing policy would > be a mistake. It all depends on the user base of the domain and the tradeoff between the benefits of having such a policy against the interoperability risks of having such a policy. We absolutely should be discouraging blind adoption of policies that result in reduced utility for email. For any domain that has non-transactional users, that takes work to assess the completeness of email authentication deployment, assess aggregate reporting to understand the likely effects of either p=quarantine or p=reject., and then evaluate the cost/benefit trade-offs associated with such policies. That's a non-trivial set of work to do and it's not cost effective for all domains to do it. Early in the deployment of SPF there was a similar push to deploy SPF records with -all (the SPF rough equivalent of p=reject). A lot of people did it without thinking it through and there were significant side effects. The community concluded that SPF Fail (due to the -all in the record matching) was not a sufficiently reliable indicator that mail should be rejected and largely stopped doing it. Aggressively pushing DMARC p=reject on domains that aren't ready for it may well lead to a similar result. Let's not. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Weakening of enforcement concern
I’m a bit concerned that the document will discourage domain owners from working toward an enforcing policy. I’ve seen at least one person say that most domains don’t need to go to p=reject. I’ve seen all sorts of domains attacked? Granted, high profile domains or perceived lucrative targets will receive the most attention but threat actors absolutely do attack all sorts of organizations all the time. Maybe I’ve misunderstood but I hope that no langue that could be construed as discouraging domain owners from moving toward an enforcing policy would be a mistake. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DSAP "DKIM Sender Authorization Protocol" for DMARC
Hector, here is my take on the DSAP proposal. I am not sold. DSAP notable features 1) DSAP policy can be used to identify and block non-mail subdomains of registered domains. This might be useful when mail-sending domains use p=(none|quarantine). The equivalent result can achieved with DMARC by setting an exact-match policy of p=(none|quarantine) on mail-sending subdomains, and a policy of sp=reject on the organizational domain. I actually think this is what domain owners should do, unless they are moving to sp=reject. However, my theoretical analysis of the problem suggests that attackers have no incentive to impersonate a non-mail subdomain when a valid mail-sending subdomain is undefended, so there is little risk of a non-mail subdomain being impersonated. 2) DSAP policy can be used to identify valid signatures from unauthorized sources. This feature becomes important if private key leakage is common, which I doubt. Feedback reports provide partial visibility into the usage of DKIM scope IDs, which may lead to detection of a key leak. Once detected, key rollover is used to disable the leaked key. Since I don't perceive leaked keys to be a significant concern for my incoming mail, I would be inclined to trust the valid signature rather than trusting the DSAP policy. 3) DSAP can be used to indicate that a message must be signed. This seems equivalent to DMARC p=reject with SFP=no policy. 4) DMARC can be used to allow mailing lists and any corollaries to sign in-place-of the originating domain. This is capability without current equivalent, but it requires the list to negotiate with all of the sending organizations to publish the authorization, and then hope that the receiving organizations will honor the signal. In most mailing list scenarios, the sending and receiving organizations are the same. So this is essentially similar to negotiating an incoming filter exception for mailing list traffic.Jesse recently mentioned replacing a mailing list with thousands of lists.Negotiating with the domain owners for all of those subscribers does not seem feasible. Even if attempted, a subset of those domain owners will say, "Not on my watch!" The scaling problem occurs when we ask how many unique mailing list domains will need to be included within a single domain's authentication list. The design would need to be flipped to use DNS subkeys, so that the number of entries was unlimited, but the lookup for any one re-signing domain returned a single record. The scaling problem is solvable for the authorized domain list, but building that list is not feasible. DF On Sat, Apr 8, 2023 at 2:01 PM Hector Santos wrote: > Summary: > > I would like to reintroduce the DSAP (DKIM Sender Authorization Protocol) > as a DMARC extended tag extension -dsap. The original DSAP draft covered > nine 1st vs 3rd party signature policies from a verifier viewpoint, which > addressed boundary conditions for DKIM signatures. The reintroduction aims > to address concerns regarding 3rd party resigners. > > Key changes proposed for DMARC integration: > > o Introduce -dsap tag for DSAP support, covering a complete range of > possible policies. > > o Use -asl tag for inline list of authorized signer support. > > o Implement -atps tag for ATPS support. > > o Formalize the From rewrite logic with a -rewrite tag. > > o Introduce -target tag to assist mail forwarders with authorized > redirection of exclusive policies. > > The proposal seeks to offer better integration with today's wide range of > mail applications, building on the existing DMARC protocol and improving > 3rd party authorization and reporting. > > > Background: > > In 2006, I submitted an I-D DSAP “DKIM Sender Authorization Protocol” that > covers the boundary conditions for 1st vs 3rd party signature > expectations. There are nine 1st vs 3rd party signature policies in DSAP > from a verifier viewpoint: > > Original 1st Party Signature (OPS) > Not expected (-) > Expected (+) > Optional (~) > > Third Party Signature (3PS) > Not expected (-) > Expected (+) > Optional (~) > > Using these expectations, DSAP can cover most if not all possible Boundary > Conditions for DKIM signatures. > > I would like to re-propose DSAP but this time as a DMARC extended tag > extension `-dsap` as I believe it can address our concerns regarding 3rd > party resigners. > > Here is the 2006 DSAP proposal I plan on updating to support DMARC and > ATPS: > > https://datatracker.ietf.org/doc/html/draft-santos-dkim-dsap-00 > > History: > > The DKIM Policy Model began with SSP “Sender Signature Practices/Policy.” > This image illustrates the overall process: > > > [image: SSP Overview] > > Many today do not realize the original DKIM included Signature Policy > protocol called SSP. It was spit into DKIM-BASE and DKIM-SSP to help > speed up the process. DKIM was well defined but SSP was not. SSP covered > various signing scenarios, however, there were 3 policies missing which >
Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists
> On Apr 10, 2023, at 12:55 PM, Murray S. Kucherawy wrote: > > I think the one thing we haven't discussed is: Could the 80-20 rule apply > here? That is, if we start off with something like what > draft-kucherawy-dkim-transform proposed (or even a trivial subset of it), > might it make enough of a dent to get us through this stalemate, and then we > can figure out what to do with the rest of it? > Speaking of Pareto: - DMARC covers only 22% of the full ranges of signature scenarios with no provision to define nor authorize 3rd party (re)signers. - Occam’s Razor, the solution is often more simpler than its often appears, 80% of the time — ATPS. Your Idea. Champion it and it will get supported by your peers. Want to try inline method? Fine. But explain why more complexity is better to reach same conclusion ATPS provides. Best option; support both to cover the different admin methods. - 80% of those who have been involved since MARID with LMAP, SPF, DKIM/, SSP, ADSP and "Super ADSP” DMARC are disillusioned why the IETF has allowed the same key cogs over 17 years to continue to perpetuate a broken protocol and problem when they never believed in SPF, ADSP and DMARC — their focus was Reputation modeling with no standard in place for an assessment lookup (opening a door for business interest). This is not about heuristics. We should first close the deterministic holes by providing domains a method to expose their 1st vs 3rd party expectations. DMARC is not a protocol complete when it comes to domain policies. Too many closes. 80%??? — HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists
> On Apr 10, 2023, at 12:55 PM, Murray S. Kucherawy wrote: >> > I think the one thing we haven't discussed is: Could the 80-20 rule apply > here? That is, if we start off with something like what > draft-kucherawy-dkim-transform proposed (or even a trivial subset of it), > might it make enough of a dent to get us through this stalemate, and then we > can figure out what to do with the rest of it? > > -MSK, participating Please consider the overall goal and the various methods to get to the same conclusion: - Inline ADID::SDID authorization (2nd signatures, new tags, complexity) - DNS lookup ADID::SDID authorization (plug and plug) The later is the more optimized method for plug and play implementation. I would rather not have to change SPF, DKIM to support a protocol incomplete ADSP/DMARC proposal. We can begin to fix this with the proper add-ons or replacement of DMARC (which is not a good idea. We want to piggyback off the lookups). DSAP provides domains a method to expose what is expected, unexpected and optional. Cover the boundary conditions to close loop holes that exist. Too many holes. — HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists
On Mon, Apr 10, 2023 at 9:55 AM Murray S. Kucherawy wrote: > On Mon, Apr 10, 2023 at 8:15 AM John Levine wrote: > >> > For certain >> >constrained but hopefully reasonable scenarios of mailing list >> >modifications, we might be able to distinguish the sources of content. >> >> People have been suggesting this forwver, but it really doesn't scale. >> There are a lot more list hosts with a lot more configurations that >> any of us have individually ever seen. In many cases they add or >> rewrite MIME parts which is extremely hard to unwind enough to see if >> a DKIM signature would have been valid. >> > > I have to agree. For as many times as this notion has been proposed, it's > never been given serious consideration, and this is the reason: We can't > possibly describe all the MLM mutations that exist, even if the mechansim > for doing so is made extensible. > > I think the one thing we haven't discussed is: Could the 80-20 rule apply > here? > +1 > That is, if we start off with something like what > draft-kucherawy-dkim-transform proposed (or even a trivial subset of it), > might it make enough of a dent to get us through this stalemate, and then > we can figure out what to do with the rest of it? > +1 I think that's a good start or some subset. -Wei > > -MSK, participating > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > smime.p7s Description: S/MIME Cryptographic Signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists
On Mon, Apr 10, 2023 at 8:15 AM John Levine wrote: > It appears that Wei Chuang said: > >1) We know that a sender intends to send a message down some path that may > >include a mailing list, that got to me safely. This is to avoid DKIM > >replay and FROM spoofing attacks. > > I think we can do that by looking at the To/Cc addresses to check if > they include the list that forwarded the mail. > +1 One approach might be to chain together recipients/sender pairs across forwarders, and sign the recipients. (Another approach might be to tie together SMTP transactions between sending-service/receiving-service pairs) > > >2) That we can identify the contributors to the content of the message in > >that path to distinguish malicious vs benign contributors. > > Isn't that what ARC is for? You can look back through the list headers > to see what the state of the message was like on the way in. While I > am not a fan of applying DMARC policies to the output of forwarders > like mailing lists, they work to filter inbound mail to a list. With ARC and a modifying mailing list, we hopefully will see that an expected DKIM-signature fails and hopefully at least a terminating ARC-Message-Signature that passes. With these tools, the receiver isn't able to see which part of the message was contributed by the sender vs the mailing list. If there's spammy content, the receiver can't distinguish which party contributed to that content, then so has to attribute that spammy content to both parties, but at the cost of harming the innocent one. Despite that issue I should mention that ARC/DMARC still helps us in knowing who your sender is, which is helpful. -Wei > > > For certain > >constrained but hopefully reasonable scenarios of mailing list > >modifications, we might be able to distinguish the sources of content. > > People have been suggesting this forwver, but it really doesn't scale. > There are a lot more list hosts with a lot more configurations that > any of us have individually ever seen. In many cases they add or > rewrite MIME parts which is extremely hard to unwind enough to see if > a DKIM signature would have been valid. > > R's, > John > smime.p7s Description: S/MIME Cryptographic Signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
I've thought about this a bit more; I could get behind "purpose> domains MUST NOT publish p=reject" (for interoperability) as long as it is made clear the interoperability context for the "MUST NOT" does not address the perceived security benefits of its current usage by domain owners at large. As said in your original message that started this topic, "... no one will be arrested or fined for choosing not to follow the [MUST NOT]", but then I feel like we still have an impasse, because it's not much of a standard if nobody adheres to said standard (as others have stated on-list), especially so in this case of strict language. The recommendation I feel from the community would probably still be, "have p=reject as a goal" even with this language in place. Possibly off-topic slightly, I think BIMI's requirement for DMARC is contradictory to what this language is trying to portray for the standard. We'd publish "general purpose domains must not publish p=reject" for DMARCbis, but then one of the pre-requisites of BIMI is to at least have p=quarantine, which still does damage due to the non-standardized way disparate receivers handle the policy. Point is, it seems conflicting to have two documents telling (and expecting) domain owners to do different things. - Mark Alley On 4/9/2023 1:33 PM, Barry Leiba wrote: > As Todd previously stated, my preference is for language that > acknowledges the primacy of the domain owner over interoperability The problem is that IETF standards are about interoperability, not about anyone’s primacy. There is an alternative, though: we can acknowledge that because of how those deploying DMARC view their needs over interoperability, DMARC is not appropriate as an IETF standard, and we abandon the effort to make it Proposed Standard. I see that as the only way forward if we cannot address the damage that improperly deployed DMARC policies do to mailing lists. Barry ___ 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] AOL-compatible mailing lists
On Sun, Apr 9, 2023 at 3:27 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > All of which is why I sketched out a very different mailing list design. > It's not my job or my agenda to sell it to people, not my job to build > the product, and not my job to deal with hurt feelings. > This, at a minimum, has the appearance of being rather cavalier and expecting a large installed base to cope with the sea change you want to impose upon them. If it's not your (or the WG's) job to sell it, build it, or deal with it, then whose job do you surmise it is? > The Internet changed when we realized that bad guys dominate the > environment, and Sender Authentication is one of the consequences. The > name-translating design provides a path to reliable list delivery when > Sender Authentication is mandatory. I think that kind of future-thinking > is what standards are supposed to do. > Standards track documents like DKIM and SPF have enjoyed relative success because they had a deployed base at the time they began their quests for standardization. They weren't written, published, and only then actually built and deployed. We had experience regarding what they look like and how effective they are in the field as part of the case for publication. Your idea might have merit, but it needs to be proven out rather than being purely theoretical. The IETF tends to favor for publication standards track documents that have implementations already. The "future-thinking" is where the idea comes from, to be sure, but it would suit us well to find a way to test them out somehow before sending them on their way. So again, who should do the work? -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists
On Mon, Apr 10, 2023 at 8:15 AM John Levine wrote: > > For certain > >constrained but hopefully reasonable scenarios of mailing list > >modifications, we might be able to distinguish the sources of content. > > People have been suggesting this forwver, but it really doesn't scale. > There are a lot more list hosts with a lot more configurations that > any of us have individually ever seen. In many cases they add or > rewrite MIME parts which is extremely hard to unwind enough to see if > a DKIM signature would have been valid. > I have to agree. For as many times as this notion has been proposed, it's never been given serious consideration, and this is the reason: We can't possibly describe all the MLM mutations that exist, even if the mechansim for doing so is made extensible. I think the one thing we haven't discussed is: Could the 80-20 rule apply here? That is, if we start off with something like what draft-kucherawy-dkim-transform proposed (or even a trivial subset of it), might it make enough of a dent to get us through this stalemate, and then we can figure out what to do with the rest of it? -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists
It appears that Wei Chuang said: >1) We know that a sender intends to send a message down some path that may >include a mailing list, that got to me safely. This is to avoid DKIM >replay and FROM spoofing attacks. I think we can do that by looking at the To/Cc addresses to check if they include the list that forwarded the mail. >2) That we can identify the contributors to the content of the message in >that path to distinguish malicious vs benign contributors. Isn't that what ARC is for? You can look back through the list headers to see what the state of the message was like on the way in. While I am not a fan of applying DMARC policies to the output of forwarders like mailing lists, they work to filter inbound mail to a list. > For certain >constrained but hopefully reasonable scenarios of mailing list >modifications, we might be able to distinguish the sources of content. People have been suggesting this forwver, but it really doesn't scale. There are a lot more list hosts with a lot more configurations that any of us have individually ever seen. In many cases they add or rewrite MIME parts which is extremely hard to unwind enough to see if a DKIM signature would have been valid. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] THIS IS ABUSE (it might be)
On Mon, 10 Apr 2023, Alessandro Vesely wrote: On Sat 08/Apr/2023 15:59:30 +0200 John Levine wrote: It appears that Eric D. Williams said: -=-=-=-=-=- I think the reliance upon list operators is properly placed on that role. It's not a DMARC problem, it's a DKIM problem, I think. No, it's a DMARC problem. DKIM didn't cause any problems for mailing lists (ignoring ill-advised and never used ADSP) until DMARC was layered on top of it, and AOL and Yahoo abused it to foist the support costs on the rest of the world after they let crooks steal their users' address books. That's how it happened. Can we now accept their push? After so many email addresses became public, how about accepting that email addresses being public doesn't have to imply that anyone can impersonate them? No, that's not what happened. People had been faking AOL and Yahoo addresses forever and the providers dealt with it. The problem was that spammers used the stolen address books to send spam from the addresses of people the recipients knew, and they were flooded with complaints "why are my friends spamming me." It's entirely the fault of those providers' poor security. Re impersonating, until DMARC can tell the difference between impersonation and the kinds of ordinary forwarding we've been doing since the 1980s, nope. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] AOL-compatible mailing lists
The AOL breach obviously just magnified a problem that was already in place - impersonation is a useful attack vector. Email addresses do not have restricted distribution, and they fall into the hands of unwanted senders all the time. We currently have a regime of semi-mandatory sender authentication. Some domain owners request it and some do not, some evaluators enforce it and some do not. Recipients assume that apparent identities can be trusted, generally without understanding the nuances between Friendly Name, From Address, and MailFrom address. At the same time, some participants (including but not limited to mailing lists) depend on absence of sender authentication, at least on their unauthenticated traffic, a practice which works only as long as their traffic is not be impersonated. The whole configuration is inherently unstable because domain owners and evaluators can change their policy at any time, and unauthenticated traffic can collect impersonators at any time. The stable designs involve no authentication and mutual distrust, or mandatory authentication. Neither outcome is likely in the short term, so the instability will persist. I don't know that our document can make much impact either way.I think language which most closely reflects reality is the tone that I have been pushing: "Sender Authentication is too important to ignore, but too imperfect to trust unconditionally." Doug Foster On Mon, Apr 10, 2023 at 2:00 AM Wei Chuang wrote: > > > On Sun, Apr 9, 2023 at 2:28 PM Murray S. Kucherawy > wrote: > >> On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster < >> dougfoster.emailstanda...@gmail.com> wrote: >> >>> As an evaluator, what I can accept is that "Some intermediaries could be >>> allowed to make some changes y do want unrestricto messages, if I have a >>> list of intermediaries that should be allowed, sufficient reason to trust >>> what they propose to do, and a reliable way to identify them."I do >>> exceptions all the time. But lists don't want to make special >>> arrangements with evaluators, and don't want to make special arrangements >>> with senders. Apparently, lists don't even want to do rigorous >>> verification to ensure that a post comes from the purported subscriber. >>> But theted access to evaluators that filter based on simplistic triggers >>> like "p=reject". >>> >> >> I see two issues with this line of thinking: >> >> (1) "I do exceptions all the time" works when you are a relatively small >> operator with a relatively small user base for whom you need to configure >> exceptions. You can get away with doing those manually. What size staff >> do you imagine GMail would need to hire to investigate and configure manual >> exceptions on a timely basis for each time one of its billion-plus users >> wants to subscribe to a mailing list? The notion screams for automation, >> and automation screams for something deterministic or at least close to it >> upon which to base automated decisions. That last bit is what's missing >> here. >> > > +1 > > >> (2) "But lists don't want to make special arrangements with evaluators, >> and don't want to make special arrangements with senders". They might, if >> there existed a reliable way to do so. How would you accomplish this in a >> way that prevents an attacker from making you think he's a list, and then >> sending whatever he wants from inside that trust boundary? >> > > +1 > > FWIW I'm starting to think this problem has two parts: > 1) We know that a sender intends to send a message down some path that may > include a mailing list, that got to me safely. This is to avoid DKIM > replay and FROM spoofing attacks. > 2) That we can identify the contributors to the content of the message in > that path to distinguish malicious vs benign contributors. For certain > constrained but hopefully reasonable scenarios of mailing list > modifications, we might be able to distinguish the sources of content. If > necessary, we can go back to first principles to determine which > modifications have to be supported. For example I've seen Brandon mention > that mailing list appending disclosure footers are required for compliance > sometimes. Others hopefully we would not have to support to reduce > implementation complexity. > > >> >> I think evaluators SHOULD NOT block on simplistic rules like p=reject, >>> because a correct p=reject block requires follow-on work to block >>> everything else from that malicious source, and should not be done >>> incorrectly. They should review, either with pre-quarantine or >>> post-audit, which is what I do. I have no problem with >>> disposition=quarantine, even for p=none. I am obligated to protect my >>> users, while also obligated to provide my users the messages they need, not >>> the ones that are technically optimal I don't understand why Big Tech and >>> its A.I. tools cannot be deployed to do the best thing. >>> >> > Simplistic rules are more likely to be
Re: [dmarc-ietf] THIS IS ABUSE (it might be)
On Sat 08/Apr/2023 15:59:30 +0200 John Levine wrote: It appears that Eric D. Williams said: -=-=-=-=-=- I think the reliance upon list operators is properly placed on that role. It's not a DMARC problem, it's a DKIM problem, I think. No, it's a DMARC problem. DKIM didn't cause any problems for mailing lists (ignoring ill-advised and never used ADSP) until DMARC was layered on top of it, and AOL and Yahoo abused it to foist the support costs on the rest of the world after they let crooks steal their users' address books. That's how it happened. Can we now accept their push? After so many email addresses became public, how about accepting that email addresses being public doesn't have to imply that anyone can impersonate them? Their move forced DMARC into a role that it wasn't design to play, but perhaps it's not so bad after all...? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
On Sun 09/Apr/2023 20:33:54 +0200 Barry Leiba wrote: There is an alternative, though: we can acknowledge that because of how those deploying DMARC view their needs over interoperability, DMARC is not appropriate as an IETF standard, and we abandon the effort to make it Proposed Standard. That sounds perfectly reasonable. If we actually /propose/ a standard, we can drop the slippery concept of general purpose domains and seek to open the era of authenticated email for every one. I see that as the only way forward if we cannot address the damage that improperly deployed DMARC policies do to mailing lists. The correct way to address that is to propose that mailing lists too authenticate their posts, so that subscribing to a mailing list doesn't entail a security risk. Let ARC prove their correct filtering and encourage receivers to override DMARC failures in MLs' streams, after subscription confirmation. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
John Levine wrote on 2023-04-09 15:55: When someone sets a DMARC policy for mail from people, it's hard to think of a time when they asked at wll whether that was what the people wanted. Or if they did, they asked something like "do you want your mail to be more secure?" which misses the point. A domain owner can set their policy without asking their users for permission. Not every sender with mail from people is a mail service provider catering to the general public. PS: I can make anyone's mail 100% secure by unplugging your mail server but I'm pretty sure that's not what you want. You can also ensure interoperability by demanding they MUST NOT use any type of authentication, because all it does is impairing mail flows, while the security benefit is nothing that IETF standards should mandate about. Neither of these extremes is helpful to actually achieve interoperability or security. Regards, Matt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] AOL-compatible mailing lists
On Sun, Apr 9, 2023 at 2:28 PM Murray S. Kucherawy wrote: > On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> As an evaluator, what I can accept is that "Some intermediaries could be >> allowed to make some changes y do want unrestricto messages, if I have a >> list of intermediaries that should be allowed, sufficient reason to trust >> what they propose to do, and a reliable way to identify them."I do >> exceptions all the time. But lists don't want to make special >> arrangements with evaluators, and don't want to make special arrangements >> with senders. Apparently, lists don't even want to do rigorous >> verification to ensure that a post comes from the purported subscriber. >> But theted access to evaluators that filter based on simplistic triggers >> like "p=reject". >> > > I see two issues with this line of thinking: > > (1) "I do exceptions all the time" works when you are a relatively small > operator with a relatively small user base for whom you need to configure > exceptions. You can get away with doing those manually. What size staff > do you imagine GMail would need to hire to investigate and configure manual > exceptions on a timely basis for each time one of its billion-plus users > wants to subscribe to a mailing list? The notion screams for automation, > and automation screams for something deterministic or at least close to it > upon which to base automated decisions. That last bit is what's missing > here. > +1 > (2) "But lists don't want to make special arrangements with evaluators, > and don't want to make special arrangements with senders". They might, if > there existed a reliable way to do so. How would you accomplish this in a > way that prevents an attacker from making you think he's a list, and then > sending whatever he wants from inside that trust boundary? > +1 FWIW I'm starting to think this problem has two parts: 1) We know that a sender intends to send a message down some path that may include a mailing list, that got to me safely. This is to avoid DKIM replay and FROM spoofing attacks. 2) That we can identify the contributors to the content of the message in that path to distinguish malicious vs benign contributors. For certain constrained but hopefully reasonable scenarios of mailing list modifications, we might be able to distinguish the sources of content. If necessary, we can go back to first principles to determine which modifications have to be supported. For example I've seen Brandon mention that mailing list appending disclosure footers are required for compliance sometimes. Others hopefully we would not have to support to reduce implementation complexity. > > I think evaluators SHOULD NOT block on simplistic rules like p=reject, >> because a correct p=reject block requires follow-on work to block >> everything else from that malicious source, and should not be done >> incorrectly. They should review, either with pre-quarantine or >> post-audit, which is what I do. I have no problem with >> disposition=quarantine, even for p=none. I am obligated to protect my >> users, while also obligated to provide my users the messages they need, not >> the ones that are technically optimal I don't understand why Big Tech and >> its A.I. tools cannot be deployed to do the best thing. >> > Simplistic rules are more likely to be deterministic and interoperate in an understandable way. Permitting exceptional cases and AI tools introduces complexity and variability as exceptions are given and AI models change. -Wei > I'm pretty sure they could, for their own use cases. But what about the > operators in between, who aren't Big Tech and don't have AI tools? A > standard has to work for everyone. > > -MSK, participating > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > smime.p7s Description: S/MIME Cryptographic Signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
