Re: [Ietf-dkim] Replay attack definition discussion
On Sun, Aug 20, 2023, at 6:13 AM, Alessandro Vesely wrote: > On Fri 18/Aug/2023 12:21:31 +0200 Emanuel Schorsch wrote: > >> > >>> For example, we have seen very large DKIM Replay attacks of youtube.com > >>> Terms of Service emails. There is no malicious content in these emails, > >>> but spammers still send very large volumes (perhaps using them to > >>> generate affinity with victims or warm up their sending > >>> infrastructure). >> > >> That points to a bug in the I-D. Section 3.1 says: > >> > >> A spammer will find a mailbox provider with a high reputation and that > >> signs their message with DKIM. The spammer sends a message with spam > >> content from there to a mailbox the spammer controls. > >> > >> Youtube.com Terms of Service emails don't seem to have been sent by the > >> spammer. > > > > I agree, for completeness we should update that section to include both > > types of DKIM replay. I can work on sending a tweak to that section. > > > Please do! Without it, Section 5.3, "Strip DKIM signatures on mailbox > delivery" makes little sense. > > > > But, to be clear this type of replay is definitely much less common than > > the spammer generated content. I just wanted to provide that it does also > > happen. > > If there is a large difference, then the idea of segmenting authentication > domains might actually belong to countering replay attacks, for spammers > looking for high reputation signatures. Some time ago I proposed > d=bullshit.example.com, but after thinking a bit more, the I-D could set up a > register for that. > > For a strawman: > >5.6. Use segmented signature domains > > Domains that host mailboxes for widely different categories of users, > typically free-mail domains, can differentiate the signature they affix > on messages by using subdomains. IANA maintains a register of > subdomains > used for this purpose (See Section 7.) > > * Messages written by spammers who get categorized as such will be > signed by subdomains with low reputation, which lowers the incentive > to obtain the very signature. > > * Careful users, who don't spam and don't have their accounts often > compromised, can use domains whose reputation won't be ruined by > replay attacks. > > And > >7. IANA Consideration > > This document proposes the use of subdomain to categorize email message > categories for which IANA is to create and maintain a new registry > entitled "DKIM Semantic Subdomain Names". > > New registrations are published in accordance with the "First Come First > Served" guidelines as described in [RFC8126]. They are to contain the > following information: > > 1. Subdomain name to be used in the category. The name MUST exist as a > direct subdomain for the domain referred by the proponent, and MUST > contain a non-empty _domainkey subdomain at the time or > registration. > > 2. Short description of the category, and criteria for assigning > messages > to this category, possibly containing a link to extended > description. > > 3. Trust that recipients are invited to assign to messages signed by > such > subdomain. This MUST be one of the key words "none", "low", > "medium" > and "high". > > 4. Date of the registration. > > Note: Domains are invited to re-use existing names rather than > registering > new ones, if the intent matches the description. These names are not > visible by users, so there is no reason to use IDNs. Names and > descriptions MUST be in English. I just want to say +1 to all of this. I believe that adding more d= signatures to convey context is the solution to allow ESPs/intermediaries to express enough information to allow receivers to make a mail handling decision in a way that minimizes collateral damage. Jesse___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
Presumably a last message of mine. Without any personal insult meant i wanted to complain on the the initial sentence Mailing-lists have long complicated email authentication. And this echoes IETF documents written a decade and longer ago (last week i looked on my local ones and i think as early as 2011). This is the stance ever since. And i always felt, and always said in public, that it is quite the opposite. It is not and has never been despite the repetitions that mailing-lists break email authentication, but quite the opposite, it is that the way that authentication was implemented broke mailing-lists, which struggle ever since. You are free to call that bullshit, but i call the above, given all the struggle that so many mailing-lists face for more than a decade, and increasing, insolent. Like i did. If the stance would change to something like saying that "operational needs required a timely solution for authentication that unfortunately degraded mailing-list operators" then that would surely sound better. Just to reiterate: the basic principle in use for email for so many years, "[alias-]forwarding" (and even i have two for only this account, CPAN and sourceforge, i am sure many active young people which work at so-and-so-many projects, and whatever, have much much more), as well as mailing-lists which tag subject lines, and insert (headers and) footers, were forcefully neglected for, in reflection, mysterious reasons, .. so i can tell *where* here the bullshit is, and who produced it. I would, if i could, strongly urge to place the burden on fixing DKIM onto DKIM, so that only DKIM has to be implemented and used everywhere (because, mind you, many do _nothing_ such, and only try to get out of the way of IETF outcome, by removing subject tags, footers, and whatever). You gain a cryptographically verifieable path from sender to receiver, and _finally_ mailing-list software is enabled to *do* anything to help authentication. Now i must admit that for copying out the above sentence, via browser, i saw the word "Prior" and that reminded me of something that Mr. Vesely said, and that, in turn, let me read some more sentences of that draft. Not more, i do not like ARC. I think the DKIM workout would work out (whatever other problems that would entail), possibly with the addition that whitespace in the base64 (encoding headers) shall be ignored so that lines can easily be broken (seems to be a deficit in the standard that artificial whitespace can be introduced, ie, RFC 5322); 'just realized that since the nmh MUA had M-L [sic] traffic on that issue (of overlong lines). (I do not need to see my name on that btw. My approach is better :)) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On Fri 18/Aug/2023 12:21:31 +0200 Emanuel Schorsch wrote: For example, we have seen very large DKIM Replay attacks of youtube.com Terms of Service emails. There is no malicious content in these emails, but spammers still send very large volumes (perhaps using them to generate affinity with victims or warm up their sending infrastructure). >> That points to a bug in the I-D. Section 3.1 says: A spammer will find a mailbox provider with a high reputation and that signs their message with DKIM. The spammer sends a message with spam content from there to a mailbox the spammer controls. Youtube.com Terms of Service emails don't seem to have been sent by the spammer. I agree, for completeness we should update that section to include both types of DKIM replay. I can work on sending a tweak to that section. Please do! Without it, Section 5.3, "Strip DKIM signatures on mailbox delivery" makes little sense. But, to be clear this type of replay is definitely much less common than the spammer generated content. I just wanted to provide that it does also happen. If there is a large difference, then the idea of segmenting authentication domains might actually belong to countering replay attacks, for spammers looking for high reputation signatures. Some time ago I proposed d=bullshit.example.com, but after thinking a bit more, the I-D could set up a register for that. For a strawman: 5.6. Use segmented signature domains Domains that host mailboxes for widely different categories of users, typically free-mail domains, can differentiate the signature they affix on messages by using subdomains. IANA maintains a register of subdomains used for this purpose (See Section 7.) * Messages written by spammers who get categorized as such will be signed by subdomains with low reputation, which lowers the incentive to obtain the very signature. * Careful users, who don't spam and don't have their accounts often compromised, can use domains whose reputation won't be ruined by replay attacks. And 7. IANA Consideration This document proposes the use of subdomain to categorize email message categories for which IANA is to create and maintain a new registry entitled "DKIM Semantic Subdomain Names". New registrations are published in accordance with the "First Come First Served" guidelines as described in [RFC8126]. They are to contain the following information: 1. Subdomain name to be used in the category. The name MUST exist as a direct subdomain for the domain referred by the proponent, and MUST contain a non-empty _domainkey subdomain at the time or registration. 2. Short description of the category, and criteria for assigning messages to this category, possibly containing a link to extended description. 3. Trust that recipients are invited to assign to messages signed by such subdomain. This MUST be one of the key words "none", "low", "medium" and "high". 4. Date of the registration. Note: Domains are invited to re-use existing names rather than registering new ones, if the intent matches the description. These names are not visible by users, so there is no reason to use IDNs. Names and descriptions MUST be in English. That's all folks Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
> > > BUT, I think this is a good idea that is separate from DKIM Replay. > > Specifically, we do see non-free mail providers as victims of DKIM > Replay as > > well. > > > If the rate is similar, I agree. That kind of information is missing from > the I-D. > > > > For example, we have seen very large DKIM Replay attacks of youtube.com > > Terms of Service emails. There is no malicious content in these emails, > but > > spammers still send very large volumes (perhaps using them to generate > > affinity with victims or warm up their sending infrastructure). > > That points to a bug in the I-D. Section 3.1 says: > > A spammer will find a mailbox provider with a high reputation and that > signs their message with DKIM. The spammer sends a message with spam > content from there to a mailbox the spammer controls. > > Youtube.com Terms of Service emails don't seem to have been sent by the > spammer. > I agree, for completeness we should update that section to include both types of DKIM replay. I can work on sending a tweak to that section. But, to be clear this type of replay is definitely much less common than the spammer generated content. I just wanted to provide that it does also happen. -Emanuel ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On Thu 17/Aug/2023 20:12:51 +0200 Emanuel Schorsch wrote: On Thu, Aug 17, 2023 at 2:06 PM Alessandro Vesely mailto:ves...@tana.it>> wrote: If corporate domains are victims of replay attacks at the same rate as free mail providers, then my theory is wrong. See below. > Ale, I think there is a lot of value in what you are saying about verification of identities and segmentation of the authenticating domain based on the tier of verification that was performed. Thanks. BUT, I think this is a good idea that is separate from DKIM Replay. Specifically, we do see non-free mail providers as victims of DKIM Replay as well. If the rate is similar, I agree. That kind of information is missing from the I-D. For example, we have seen very large DKIM Replay attacks of youtube.com Terms of Service emails. There is no malicious content in these emails, but spammers still send very large volumes (perhaps using them to generate affinity with victims or warm up their sending infrastructure). That points to a bug in the I-D. Section 3.1 says: A spammer will find a mailbox provider with a high reputation and that signs their message with DKIM. The spammer sends a message with spam content from there to a mailbox the spammer controls. Youtube.com Terms of Service emails don't seem to have been sent by the spammer. Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On Thu, Aug 17, 2023, at 5:30 AM, Alessandro Vesely wrote: > When domain authentication arrived, they considered that /all/ messages from > their domain must be authenticated. Some receivers only send FBLs if the messages are DKIM=pass. So, the responsible thing to do is for a MBP/ESP to sign everything to maximize visibility on abuse. > DMARC reporting is specifically aimed at such goal. MBP/ESPs which allow customers to bring their own domain do not have visibility into DMARC reports; especially from bad actors who don't want their provider to see what they are doing. Jesse___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On Thu, Aug 17, 2023 at 2:06 PM Alessandro Vesely wrote: > On Thu 17/Aug/2023 18:21:35 +0200 Murray S. Kucherawy wrote: > > On Thu, Aug 17, 2023 at 3:30 AM Alessandro Vesely > wrote: > > > >>> I'm not convinced advice is necessary here. Do you really need signs > in > >>> banks that say "Don't put your signature on random financial > documents"? I > >>> have to believe that people understand what it means to sign > something, and > >>> why they shouldn't do that. > >> > >> Well, when banks don't do that, they're in bad faith. Consider, for > >> example, derivative financial contracts conceived so that nobody is > able > >> to read them —banks don't even try to print them. Decadent practices. > > > I don't know what you mean by "decadent", here or below. > > > > I disagree about the "bad faith" claim. I think everyone with their own > > agency understands what it means to affix their signature to something. > > It's on them to understand that fully, or assume the risks of not being > > diligent. > > > When a customer who is dedicating (part of) an afternoon to banking has to > /fully understand/ a 600 page agreement, the only choice he has is to > assume > the risk and blindly trust the bank. You may disagree that that is bad > faith. > It's the kind of thing I'd call decadent. > > > > In the case of high volume operations like scanning email, the scale > forces > > you to play the odds that your inbound filtering gets it right a high > > enough percentage of the time that you're able to cope somehow with the > > things that slip through. > > > Yeah, here too you are forced to take the risk. Domains who trust their > users > have easier options. > > > >> Domains cannot "read" the messages they sign. Some MPs may have > wonderful > >> anti-spam filters, but that's still not the same as reading and signing > an > >> agreement. We need to dismantle the agreement metaphor a bit. > > > > The logical extension of this line of thinking is that message > > authentication isn't meaningful. Is that where you're going with this? > > > No, the opposite. Message authentication allows a system to vet messages > without understanding their content, if it trusts the authenticated > entities. > > > >> On the other hand, there are domains which blindly sign anything their > >> users write, enacting only minimal limits to prevent abuse in case of > >> compromised credentials. They can afford doing so because, for > example, > >> users are employees and are known in person. Do such domains > experience > >> replay attacks? > > > Likely. So? > > > If corporate domains are victims of replay attacks at the same rate as > free > mail providers, then my theory is wrong. See below. > Ale, I think there is a lot of value in what you are saying about verification of identities and segmentation of the authenticating domain based on the tier of verification that was performed. BUT, I think this is a good idea that is separate from DKIM Replay. Specifically, we do see non-free mail providers as victims of DKIM Replay as well. For example, we have seen very large DKIM Replay attacks of youtube.com Terms of Service emails. There is no malicious content in these emails, but spammers still send very large volumes (perhaps using them to generate affinity with victims or warm up their sending infrastructure). ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On Thu 17/Aug/2023 18:21:35 +0200 Murray S. Kucherawy wrote: On Thu, Aug 17, 2023 at 3:30 AM Alessandro Vesely wrote: I'm not convinced advice is necessary here. Do you really need signs in banks that say "Don't put your signature on random financial documents"? I have to believe that people understand what it means to sign something, and why they shouldn't do that. Well, when banks don't do that, they're in bad faith. Consider, for example, derivative financial contracts conceived so that nobody is able to read them —banks don't even try to print them. Decadent practices. > I don't know what you mean by "decadent", here or below. I disagree about the "bad faith" claim. I think everyone with their own agency understands what it means to affix their signature to something. It's on them to understand that fully, or assume the risks of not being diligent. When a customer who is dedicating (part of) an afternoon to banking has to /fully understand/ a 600 page agreement, the only choice he has is to assume the risk and blindly trust the bank. You may disagree that that is bad faith. It's the kind of thing I'd call decadent. In the case of high volume operations like scanning email, the scale forces you to play the odds that your inbound filtering gets it right a high enough percentage of the time that you're able to cope somehow with the things that slip through. Yeah, here too you are forced to take the risk. Domains who trust their users have easier options. Domains cannot "read" the messages they sign. Some MPs may have wonderful anti-spam filters, but that's still not the same as reading and signing an agreement. We need to dismantle the agreement metaphor a bit. The logical extension of this line of thinking is that message authentication isn't meaningful. Is that where you're going with this? No, the opposite. Message authentication allows a system to vet messages without understanding their content, if it trusts the authenticated entities. On the other hand, there are domains which blindly sign anything their users write, enacting only minimal limits to prevent abuse in case of compromised credentials. They can afford doing so because, for example, users are employees and are known in person. Do such domains experience replay attacks? > Likely. So? If corporate domains are victims of replay attacks at the same rate as free mail providers, then my theory is wrong. See below. What I'm trying to address is the relationship between users and mailbox providers. Free MPs want anyone to be able to create a free account, and that was at the root of their success. When domain authentication arrived, they considered that /all/ messages from their domain must be authenticated. DMARC reporting is specifically aimed at such goal. For something that signs at a domain level, why is this something with which we should concern ourselves? Domains sign messages so that receivers can be sure about the origin. The reputation a domain earns is then related to the amount of spam. Trusted users, such as employees using a corporate domain, don't spam. Therefore, spam emitted by such domain is proportional to the likelihood that its accounts get compromised. My theory is that free mail providers and ESPs offering free trials host bad users whose purpose is to spam, either through replay or other kind of attacks. This would result an an increased amount of reply attacks at such domains. That's what I gathered from the I-D and this list's posts. I repeatedly asked to narrate some real cases, but didn't hear any. So I may be wrong. The arms race you refer is the result of indiscriminately accepting all users. A small percentage of them are bad actors, but cannot be identified because, in general, the real IDs of users is not ascertained. At what point does claiming responsibility for non-ascertained entities results in decadent practices? > Again, I don't know what this means. By decadent I mean a practice of signing while the value of verified signatures gradually declines. Signing for any Tom, Dick and Harry becomes just noise. There is no equivalence between authenticating subscribers and scanning what they write. Both tasks need human intelligence, but the former doesn't have to be done on each message. Scanning w/o intelligence is only heuristic and relies heavily on volume limits, which is where replay attacks get away with it. > ...and this is entirely an internal matter. Are you arguing that this deserves protocol-level consideration? If the above theory is correct, a "potential solution" could be added to the I-D with considerations about varying signature ranks for domains with mixed users types. If you're going to assert that Gmail should authenticate their users before allowing them to send stuff that will be signed, then I'm pretty sure they do that already. I think they know much
Re: [Ietf-dkim] Replay attack definition discussion
On Thu, Aug 17, 2023 at 3:30 AM Alessandro Vesely wrote: > > I'm not convinced advice is necessary here. Do you really need signs in > > banks that say "Don't put your signature on random financial > documents"? I > > have to believe that people understand what it means to sign something, > and > > why they shouldn't do that. > > Well, when banks don't do that, they're in bad faith. Consider, for > example, > derivative financial contracts conceived so that nobody is able to read > them > —banks don't even try to print them. Decadent practices. > I don't know what you mean by "decadent", here or below. I disagree about the "bad faith" claim. I think everyone with their own agency understands what it means to affix their signature to something. It's on them to understand that fully, or assume the risks of not being diligent. In the case of high volume operations like scanning email, the scale forces you to play the odds that your inbound filtering gets it right a high enough percentage of the time that you're able to cope somehow with the things that slip through. > Domains cannot "read" the messages they sign. Some MPs may have wonderful > anti-spam filters, but that's still not the same as reading and signing an > agreement. We need to dismantle the agreement metaphor a bit. > The logical extension of this line of thinking is that message authentication isn't meaningful. Is that where you're going with this? > On the other hand, there are domains which blindly sign anything their > users > write, enacting only minimal limits to prevent abuse in case of > compromised > credentials. They can afford doing so because, for example, users are > employees and are known in person. Do such domains experience replay > attacks? > Likely. So? > What I'm trying to address is the relationship between users and mailbox > providers. Free MPs want anyone to be able to create a free account, and > that > was at the root of their success. When domain authentication arrived, > they > considered that /all/ messages from their domain must be authenticated. > DMARC > reporting is specifically aimed at such goal. > For something that signs at a domain level, why is this something with which we should concern ourselves? > The arms race you refer is the result of indiscriminately accepting all > users. > A small percentage of them are bad actors, but cannot be identified > because, in > general, the real IDs of users is not ascertained. At what point does > claiming > responsibility for non-ascertained entities results in decadent practices? > Again, I don't know what this means. > There is no equivalence between authenticating subscribers and scanning > what > they write. Both tasks need human intelligence, but the former doesn't > have to > be done on each message. Scanning w/o intelligence is only heuristic and > relies heavily on volume limits, which is where replay attacks get away > with it. > ...and this is entirely an internal matter. Are you arguing that this deserves protocol-level consideration? If you're going to assert that Gmail should authenticate their users before allowing them to send stuff that will be signed, then I'm pretty sure they do that already. -MSK, participating, but currently quite confused ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On Wed 16/Aug/2023 20:19:44 +0200 Dave Crocker wrote: On 8/16/2023 10:48 AM, Murray^W Ale wrote: Yet, an open signer is for DKIM the equivalent of what an open relay is for SPF. It is nothing of the sort. Open relays perform a relaying function, which actively moves mail, where the abuse is a) obfuscation, and b) fan-out. Yup, I meant just from an SPF point of view, without the SMTP part. What you are calling open signer allows adding any domain's authenticated identity onto the message, which permits other sites to develop and evaluate the reputation of the mail stream that uses the identity. The former is abuse. The second is potentially useful. Since you think otherwise, please explain. Maybe, instead of an open relay, I should've considered a site publishing this: "v=spf1 ip4:0.0.0.0/1 ip4:128.0.0.0/1 ip6:0::/1 ip6:8000::/1 +all" So it doesn't perform the moving function. Either produces a waste of authentication checks at receivers. Everybody can get anything authenticated. The reputation others can develop from that is white noise. I don't think it's useful. Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On Wed 16/Aug/2023 19:48:30 +0200 Murray S. Kucherawy wrote: On Wed, Aug 16, 2023 at 10:25 AM Alessandro Vesely wrote: On Wed 16/Aug/2023 15:26:43 +0200 Laura Atkins wrote: On 16 Aug 2023, at 12:59, Alessandro Vesely wrote: On Wed 16/Aug/2023 11:17:50 +0200 Laura Atkins wrote: On 16 Aug 2023, at 09:57, Alessandro Vesely wrote: How about enacting common sense rules such as Never sign anything without reading the small print? In the same way that users agree to any Terms & Conditions without reading, domains sign any mail their users send without knowing. Decadent practices, aren't they? Can you expand on this? I’m not sure I understand how reading the content will fix the problem. Spam is an issue of volume mostly. Avoiding to /sign without knowing/ could perhaps partially solve the problem. Reading the content was just for comparison with signing agreements. Without knowing what, though? I am just not understanding what Sorry, I meant without knowing who is the author. According to RFC 6373, "DKIM separates the question of the identity of the Signer of the message from the purported author of the message." Yet, an open signer is for DKIM the equivalent of what an open relay is for SPF. > I'm not convinced advice is necessary here. Do you really need signs in banks that say "Don't put your signature on random financial documents"? I have to believe that people understand what it means to sign something, and why they shouldn't do that. Well, when banks don't do that, they're in bad faith. Consider, for example, derivative financial contracts conceived so that nobody is able to read them —banks don't even try to print them. Decadent practices. We're already saying that a valid DKIM signature means the signer takes "some" responsibility for the message. Saying "Don't sign random things" seems redundant to me; it presumes the first sentence is somehow deficient or hard to understand. Is that what you're claiming? Domains cannot "read" the messages they sign. Some MPs may have wonderful anti-spam filters, but that's still not the same as reading and signing an agreement. We need to dismantle the agreement metaphor a bit. If this reduces to "Don't sign spam," then I don't think we need to say that. Wei or Emmanual can confirm to be sure, but I'm pretty certain Google doesn't sign absolutely anything, in the sense that if you connect to them, authenticate, and then start spraying spam, it's going to get detected and disallowed somehow. The problem occurs when someone finds a way through the spam filters. I worked for a spam filtering company for a few years, but it doesn't take such direct experience to realize that it's an arms race: Attackers are trying to figure out what won't get caught and then exploiting that until the service provider catches up; rinse, repeat. That gap will always come and go, and to assert that the gap should never ever be there and the service provider should be ashamed of itself if it ever occurs seems unrealistic to me. On the other hand, there are domains which blindly sign anything their users write, enacting only minimal limits to prevent abuse in case of compromised credentials. They can afford doing so because, for example, users are employees and are known in person. Do such domains experience replay attacks? What I'm trying to address is the relationship between users and mailbox providers. Free MPs want anyone to be able to create a free account, and that was at the root of their success. When domain authentication arrived, they considered that /all/ messages from their domain must be authenticated. DMARC reporting is specifically aimed at such goal. But domain authentication was conceived as a coarse-grained form of authentication where the responsibility that a domain claims is meaningful as long as membership to that domain qualifies an author in some way. The arms race you refer is the result of indiscriminately accepting all users. A small percentage of them are bad actors, but cannot be identified because, in general, the real IDs of users is not ascertained. At what point does claiming responsibility for non-ascertained entities results in decadent practices? To repeat my questions, then, would limiting (qualified) DKIM signatures to verified accounts diminish replay attacks by any amount? Is this kind of solution acceptable? Sure, you should only sign things if you have reason to believe the source and the content are such that you're willing to attach your good name to it. Whether that's authentication of the submitter or scanning of the content, or both, or other checks, is entirely up to you. But by saying "you take some responsibility" for messages, I think we're already saying that and don't need to repeat ourselves. There is no equivalence between authenticating subscribers and scanning what they write. Both tasks need human intelligence, but the
Re: [Ietf-dkim] Replay attack definition discussion
On Wed, Aug 16, 2023, at 8:26 AM, Laura Atkins wrote: > > >> On 16 Aug 2023, at 12:59, Alessandro Vesely wrote: > >> BTW, how many replay attacks does an average ESP or MP notice in one month? > > Maybe representatives of either group could offer numbers. ESPs have limited visibility because feedback is mostly sent to the whois contact of the infrastructure emitting the replay (unless specific feedback mechanics are set up for DKIM signers) https://www.rfc-editor.org/rfc/rfc6650#section-5.3 Where an abusive message is authenticated using a domain-level authentication technology such as DKIM [RFC6376] or SPF [RFC4408], the domain that has been verified by the authentication mechanism is often a reasonable candidate for receiving feedback about the message. For DKIM, though, while the authenticated domain has some responsibility for the mail sent, it can be a poor contact point for abuse issues (for example, it could represent the message's author but not its sender, it could identify the bad actor responsible for the message, or it could refer to a domain that cannot receive mail at all). Jesse___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
> On Aug 16, 2023, at 11:21, Jim Fenton wrote: > > On 16 Aug 2023, at 10:57, Jon Callas wrote: > >>> On Aug 16, 2023, at 10:25, Alessandro Vesely wrote: >>> >>> To repeat my questions, then, would limiting (qualified) DKIM signatures to >>> verified accounts diminish replay attacks by any amount? Is this kind of >>> solution acceptable? >> >> There's two reasons that this isn't acceptable. One is that DKIM is >> domain-level signing, not user-level signing, and that's been so since the >> beginning. DKIM is *intentionally* designed with that as an anti-goal. The >> second is the historical use of email, where addresses are not accounts. > > Deciding whether to apply a DKIM signature based on the submitting user is > not the same thing as user-level signing. Signers can use any criteria they > want in deciding whether to sign an outgoing message. I think that's another facet of what I'm trying to say. The statements in the message are only loosely connected to the account underneath. > >> In that second historic case, it's not acceptable because there are lots of >> cases out there where there are virtual addresses, not really an account, >> and yet from time to time a message has to be sent with a `From` of that >> address. > > I have lots of virtual addresses. When submitting a message to my outgoing > MTA, I still authenticate to it as myself. If my outgoing MTA served multiple > users, it should check whether the From address corresponded to my account. > In the situation Ale is considering, the decision on whether to sign or not > would depend on the submitting user, which is not necessarily the From > address on the message. Yes, this is exactly my use case, too, and many MTAs let an authenticated user send anything they want. Many others accept an arbitrary message, but might later on, bounce it back to user. I think we're in violent agreement on this? Jon ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On 8/16/2023 11:23 AM, Murray S. Kucherawy wrote: For the record, the attribution here is wrong. That was Alessandro's comment, not mine. drat. sorry. the downside of trying to compress quoted text. this was not a lossless compression... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On 8/16/2023 11:21 AM, Jim Fenton wrote: If my outgoing MTA served multiple users, it should check whether the From address corresponded to my account. or not check, depending on the operational environment. that is, there are providers where this is a good thing to do but others where it is quite a bad thing to do. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On Wed, Aug 16, 2023 at 11:19 AM Dave Crocker wrote: > On 8/16/2023 10:48 AM, Murray S. Kucherawy wrote: > > Yet, an open > > signer is for DKIM the equivalent of what an open relay is for SPF. > > It is nothing of the sort. > > [...] > For the record, the attribution here is wrong. That was Alessandro's comment, not mine. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On 16 Aug 2023, at 10:57, Jon Callas wrote: >> On Aug 16, 2023, at 10:25, Alessandro Vesely wrote: >> >> To repeat my questions, then, would limiting (qualified) DKIM signatures to >> verified accounts diminish replay attacks by any amount? Is this kind of >> solution acceptable? > > There's two reasons that this isn't acceptable. One is that DKIM is > domain-level signing, not user-level signing, and that's been so since the > beginning. DKIM is *intentionally* designed with that as an anti-goal. The > second is the historical use of email, where addresses are not accounts. Deciding whether to apply a DKIM signature based on the submitting user is not the same thing as user-level signing. Signers can use any criteria they want in deciding whether to sign an outgoing message. > In that second historic case, it's not acceptable because there are lots of > cases out there where there are virtual addresses, not really an account, and > yet from time to time a message has to be sent with a `From` of that address. I have lots of virtual addresses. When submitting a message to my outgoing MTA, I still authenticate to it as myself. If my outgoing MTA served multiple users, it should check whether the From address corresponded to my account. In the situation Ale is considering, the decision on whether to sign or not would depend on the submitting user, which is not necessarily the From address on the message. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On 8/16/2023 10:48 AM, Murray S. Kucherawy wrote: Yet, an open signer is for DKIM the equivalent of what an open relay is for SPF. It is nothing of the sort. Open relays perform a relaying function, which actively moves mail, where the abuse is a) obfuscation, and b) fan-out. What you are calling open signer allows adding any domain's authenticated identity onto the message, which permits other sites to develop and evaluate the reputation of the mail stream that uses the identity. The former is abuse. The second is potentially useful. Since you think otherwise, please explain. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
> On Aug 16, 2023, at 10:25, Alessandro Vesely wrote: > > To repeat my questions, then, would limiting (qualified) DKIM signatures to > verified accounts diminish replay attacks by any amount? Is this kind of > solution acceptable? There's two reasons that this isn't acceptable. One is that DKIM is domain-level signing, not user-level signing, and that's been so since the beginning. DKIM is *intentionally* designed with that as an anti-goal. The second is the historical use of email, where addresses are not accounts. In that second historic case, it's not acceptable because there are lots of cases out there where there are virtual addresses, not really an account, and yet from time to time a message has to be sent with a `From` of that address. Example: there's i...@example.com, and that goes to both Alice and Bob, via a Postfix virtual address (or an internal organization group). There's no account of info, the vast majority of the time email is only incoming, but from time to time a message has to be sent From that. On that, take the case where spam starts coming in from ads@store and to unsubscribe they have to send a message from info, not Alice nor Bob. There's even a single-person version of this, the user+t...@example.com convention, and variations on that, such as the way that Gmail considers a dot to be optional. The address first.last@gmail is the same as firstlast@gmail and even f.i.r.s.t.l.a.s.t@gmail. In a real-world example of the broader issue, my partner and I have an email address that goes to the both of us. It's the contact email for airlines, concerts, and so on, so that we both get it. A few years ago, it was literally a Postfix virtual entry. Presently, it's a Google Group because there's no equivalent of a virtual fan-out there. Once or twice a year one of us has to send a message from there. We don't want a separate account because that costs money (and is annoying). The bottom line is that ambiguous, organizational, and virtual addresses exist, and have to be taken into consideration. Jon ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On Wed, Aug 16, 2023 at 10:25 AM Alessandro Vesely wrote: > On Wed 16/Aug/2023 15:26:43 +0200 Laura Atkins wrote: > >> On 16 Aug 2023, at 12:59, Alessandro Vesely wrote: > >> On Wed 16/Aug/2023 11:17:50 +0200 Laura Atkins wrote: > On 16 Aug 2023, at 09:57, Alessandro Vesely wrote: > How about enacting common sense rules such as Never sign anything > without reading the small print? In the same way that users agree to any > Terms & Conditions without reading, domains sign any mail their users send > without knowing. Decadent practices, aren't they? > >>> Can you expand on this? I’m not sure I understand how reading the > content will fix the problem. Spam is an issue of volume mostly. > >> > >> Avoiding to /sign without knowing/ could perhaps partially solve the > problem. Reading the content was just for comparison with signing > agreements. > > > > Without knowing what, though? I am just not understanding what > > Sorry, I meant without knowing who is the author. > > According to RFC 6373, "DKIM separates the question of the identity of the > Signer of the message from the purported author of the message." Yet, an > open > signer is for DKIM the equivalent of what an open relay is for SPF. > I'm not convinced advice is necessary here. Do you really need signs in banks that say "Don't put your signature on random financial documents"? I have to believe that people understand what it means to sign something, and why they shouldn't do that. We're already saying that a valid DKIM signature means the signer takes "some" responsibility for the message. Saying "Don't sign random things" seems redundant to me; it presumes the first sentence is somehow deficient or hard to understand. Is that what you're claiming? If this reduces to "Don't sign spam," then I don't think we need to say that. Wei or Emmanual can confirm to be sure, but I'm pretty certain Google doesn't sign absolutely anything, in the sense that if you connect to them, authenticate, and then start spraying spam, it's going to get detected and disallowed somehow. The problem occurs when someone finds a way through the spam filters. I worked for a spam filtering company for a few years, but it doesn't take such direct experience to realize that it's an arms race: Attackers are trying to figure out what won't get caught and then exploiting that until the service provider catches up; rinse, repeat. That gap will always come and go, and to assert that the gap should never ever be there and the service provider should be ashamed of itself if it ever occurs seems unrealistic to me. To repeat my questions, then, would limiting (qualified) DKIM signatures to > verified accounts diminish replay attacks by any amount? Is this kind of > solution acceptable? > Sure, you should only sign things if you have reason to believe the source and the content are such that you're willing to attach your good name to it. Whether that's authentication of the submitter or scanning of the content, or both, or other checks, is entirely up to you. But by saying "you take some responsibility" for messages, I think we're already saying that and don't need to repeat ourselves. -MSK, participating ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On Wed 16/Aug/2023 15:26:43 +0200 Laura Atkins wrote: On 16 Aug 2023, at 12:59, Alessandro Vesely wrote: On Wed 16/Aug/2023 11:17:50 +0200 Laura Atkins wrote: On 16 Aug 2023, at 09:57, Alessandro Vesely wrote: How about enacting common sense rules such as Never sign anything without reading the small print? In the same way that users agree to any Terms & Conditions without reading, domains sign any mail their users send without knowing. Decadent practices, aren't they? Can you expand on this? I’m not sure I understand how reading the content will fix the problem. Spam is an issue of volume mostly. Avoiding to /sign without knowing/ could perhaps partially solve the problem. Reading the content was just for comparison with signing agreements. Without knowing what, though? I am just not understanding what Sorry, I meant without knowing who is the author. According to RFC 6373, "DKIM separates the question of the identity of the Signer of the message from the purported author of the message." Yet, an open signer is for DKIM the equivalent of what an open relay is for SPF. Does Google know the real ID of its users? I'd guess in many cases they do; for example, Google does payments and bank stuff which do require real IDs (I pay, therefore I am). Nevertheless, they sign all email messages with the same d=gmail.com, irrespective of user reputation. I fully understand the right to anonymity. I know it's in the First Amendment, in the US. However, I figure users should trust their mailbox providers enough to disclose their real ID. The minority of people who really need to care about that can always find a provider in countries where ISPs cannot be forced to disclosure, or suffer sending lower grade mail. Would that be an acceptable kind of solution? I’m not sure I understand how this is a solution. As Evan and Emanuel have both said the bad actors have access to many thousands of accounts that look like real accounts. In my own experience, they have access to validating credit cards which is one of the most common ways to validate a real identity online. There is an ongoing effort to safeguard digital identities (and plaguing people with 2FAs). Checking IDs must be possible, and should be done in a number of cases. Perhaps free mailbox providers could contribute...? But 2FAs isn’t a realID, it’s just 2FA. True. When I happen to need 2FA it is for sites who know my real ID. Yet 2FA by itself doesn't bring that info. Before digressing about methods, the question is whether limiting signing to known (good) users could mitigate the replay problem. Suppose an ESP or MP only signs mail authored by people who subscribed more than one month ago, and whose ID was verified less than six months ago. Would that diminish replay attacks by any amount? Given what I know of how spammers work, one month and 6 months to warm an account is trivial and something that a lot of spammers already bake into their setup processes. You know this subject better than I. I just said 6 months after how orgs like PGP Global Directory and Let's Encrypt behave. Let's not digress about methods for a moment. In the UE there are electronic ID cards issued by governments. In Italy, the government additionally established SPID[*] whereby private ID providers can grant access to various sites. They are both grounded on credentials emitted after in person contact. Banks don't use SPID, but AFAIK require in person contact in order to create accounts. Then, obviously, any method to verify an ID has weak points and bad actors will always slip through the cracks. However, with what percentage of success? Since we're interested in volumes, a relevant quote of success is enough. Email addresses are already often used as digital IDs, and I'm sure MPs make considerable efforts to keep them safe. Yet, that can be improved. To wit, while I saw several times Google vans acquiring the reality of streets, I never saw a Google officer acquiring the reality of user IDs. How do large MPs manage accounts? Don't they categorize them with some sort of trust indicator, like, say, inactive accounts, personal accounts, amount of traffic, in/out ratio, percentage of bounces and the like? The kind of solution I'm trying to propose is about why DKIM signatures don't vary according on such indicator —if it exists. The digital environment which is emerging deserves valid IDs anyway. For example, are we able to enter job positions or sign agreements online? Such abilities can be easily seen as a must for economic boost. So can we assume that it is possible to determine real IDs of email accounts with reasonable accuracy? To repeat my questions, then, would limiting (qualified) DKIM signatures to verified accounts diminish replay attacks by any amount? Is this kind of solution acceptable? Best Ale -- [*] https://www.spid.gov.it/en/what-is-spid/
Re: [Ietf-dkim] Replay attack definition discussion
> On 16 Aug 2023, at 12:59, Alessandro Vesely wrote: > > On Wed 16/Aug/2023 11:17:50 +0200 Laura Atkins wrote: >>> On 16 Aug 2023, at 09:57, Alessandro Vesely wrote: >>> How about enacting common sense rules such as Never sign anything without >>> reading the small print? In the same way that users agree to any Terms & >>> Conditions without reading, domains sign any mail their users send without >>> knowing. Decadent practices, aren't they? >> Can you expand on this? I’m not sure I understand how reading the content >> will fix the problem. Spam is an issue of volume mostly. > > > Avoiding to /sign without knowing/ could perhaps partially solve the problem. > Reading the content was just for comparison with signing agreements. Without knowing what, though? I am just not understanding what >>> Does Google know the real ID of its users? I'd guess in many cases they >>> do; for example, Google does payments and bank stuff which do require real >>> IDs (I pay, therefore I am). Nevertheless, they sign all email messages >>> with the same d=gmail.com, irrespective of user reputation. >>> I fully understand the right to anonymity. I know it's in the First >>> Amendment, in the US. However, I figure users should trust their mailbox >>> providers enough to disclose their real ID. The minority of people who >>> really need to care about that can always find a provider in countries >>> where ISPs cannot be forced to disclosure, or suffer sending lower grade >>> mail. >>> Would that be an acceptable kind of solution? >> I’m not sure I understand how this is a solution. As Evan and Emanuel have >> both said the bad actors have access to many thousands of accounts that look >> like real accounts. In my own experience, they have access to validating >> credit cards which is one of the most common ways to validate a real >> identity online. > > > There is an ongoing effort to safeguard digital identities (and plaguing > people with 2FAs). Checking IDs must be possible, and should be done in a > number of cases. Perhaps free mailbox providers could contribute...? But 2FAs isn’t a realID, it’s just 2FA. > Before digressing about methods, the question is whether limiting signing to > known (good) users could mitigate the replay problem. Suppose an ESP or MP > only signs mail authored by people who subscribed more than one month ago, > and whose ID was verified less than six months ago. Would that diminish > replay attacks by any amount? Given what I know of how spammers work, one month and 6 months to warm an account is trivial and something that a lot of spammers already bake into their setup processes. > BTW, how many replay attacks does an average ESP or MP notice in one month? Maybe representatives of either group could offer numbers. > Is it legal to mount replay attacks? > Was any user responsible for replay attacks ever identified and prosecuted? I am not a lawyer and unqualified to address these questions. laura (participating) -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On Wed 16/Aug/2023 11:17:50 +0200 Laura Atkins wrote: On 16 Aug 2023, at 09:57, Alessandro Vesely wrote: How about enacting common sense rules such as Never sign anything without reading the small print? In the same way that users agree to any Terms & Conditions without reading, domains sign any mail their users send without knowing. Decadent practices, aren't they? Can you expand on this? I’m not sure I understand how reading the content will fix the problem. Spam is an issue of volume mostly. Avoiding to /sign without knowing/ could perhaps partially solve the problem. Reading the content was just for comparison with signing agreements. Does Google know the real ID of its users? I'd guess in many cases they do; for example, Google does payments and bank stuff which do require real IDs (I pay, therefore I am). Nevertheless, they sign all email messages with the same d=gmail.com, irrespective of user reputation. I fully understand the right to anonymity. I know it's in the First Amendment, in the US. However, I figure users should trust their mailbox providers enough to disclose their real ID. The minority of people who really need to care about that can always find a provider in countries where ISPs cannot be forced to disclosure, or suffer sending lower grade mail. Would that be an acceptable kind of solution? I’m not sure I understand how this is a solution. As Evan and Emanuel have both said the bad actors have access to many thousands of accounts that look like real accounts. In my own experience, they have access to validating credit cards which is one of the most common ways to validate a real identity online. There is an ongoing effort to safeguard digital identities (and plaguing people with 2FAs). Checking IDs must be possible, and should be done in a number of cases. Perhaps free mailbox providers could contribute...? Before digressing about methods, the question is whether limiting signing to known (good) users could mitigate the replay problem. Suppose an ESP or MP only signs mail authored by people who subscribed more than one month ago, and whose ID was verified less than six months ago. Would that diminish replay attacks by any amount? BTW, how many replay attacks does an average ESP or MP notice in one month? Is it legal to mount replay attacks? Was any user responsible for replay attacks ever identified and prosecuted? Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
> On 16 Aug 2023, at 09:57, Alessandro Vesely wrote: > > On Tue 15/Aug/2023 14:59:18 +0200 Laura Atkins wrote: >>> On 15 Aug 2023, at 12:36, Alessandro Vesely wrote: >>> On Tue 15/Aug/2023 08:10:23 +0200 Bron Gondwana wrote: >> "Problem solved." [...] > > > Hm.. More than defining the replay attack, we need to define what kind of > solution is acceptable. The Basic solution space the I-D proposes doesn't > include limiting what messages are signed by a domain. > > We've love to not sign spam at all, but short of never allowing users to send email, it's not actually possible. We're not trying to "accomodate sites that send spam", we're trying to minimise the blast damage of a message that a bad actor manages to get signed - because that reduces that value of getting such a message stamped with a signature, and that reduces the amount of spam. >>> Still, knowing that he's a bad actor, you could skip signing. Are there so >>> many new spammers every day? Or, rather, there is a bunch of professional >>> spammers who know how to hide? >> How do you know he’s a bad actor before he does a bad action? That’s the >> crux of the problem: > > > Very much agreed. > > >> the bad actor looks very much like a not-bad actor. You can’t generally tell >> the difference between the two until after the bad action has happened. In >> fact, the bad actor is often going to try and look as much like a not-bad >> actor as possible. That doesn’t mean they can’t be tracked. They are, and >> many of them get shut down based on patterns and vetting and a lot of things. > > > Tracking and shooting down is good. However, as you note, it is not enough. > > How about enacting common sense rules such as Never sign anything without > reading the small print? In the same way that users agree to any Terms & > Conditions without reading, domains sign any mail their users send without > knowing. Decadent practices, aren't they? Can you expand on this? I’m not sure I understand how reading the content will fix the problem. Spam is an issue of volume mostly. > Does Google know the real ID of its users? I'd guess in many cases they do; > for example, Google does payments and bank stuff which do require real IDs (I > pay, therefore I am). Nevertheless, they sign all email messages with the > same d=gmail.com, irrespective of user reputation. > > I fully understand the right to anonymity. I know it's in the First > Amendment, in the US. However, I figure users should trust their mailbox > providers enough to disclose their real ID. The minority of people who > really need to care about that can always find a provider in countries where > ISPs cannot be forced to disclosure, or suffer sending lower grade mail. > > Would that be an acceptable kind of solution? I’m not sure I understand how this is a solution. As Evan and Emanuel have both said the bad actors have access to many thousands of accounts that look like real accounts. In my own experience, they have access to validating credit cards which is one of the most common ways to validate a real identity online. laura (participating) >> But the reality is: bad-actors are going to get through every process. If we >> could ID spammers up front and stop them from spamming we’d very likely have >> done it already. In this case, they’re using DKIM in a way that was foreseen >> by the original authors but not treated as something that needed to be >> addressed in the protocol. > > > Yes, replay was considered. Indeed, most protocol-change ideas being > proposed these days turn out to have been already drafted at the time. > Anyway, changing DKIM doesn't seem to be something that will have practical > effects in the short and medium term. Consider ed25519, which is so > straightforward to implement. -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On Tue 15/Aug/2023 14:59:18 +0200 Laura Atkins wrote: On 15 Aug 2023, at 12:36, Alessandro Vesely wrote: On Tue 15/Aug/2023 08:10:23 +0200 Bron Gondwana wrote: "Problem solved." [...] Hm.. More than defining the replay attack, we need to define what kind of solution is acceptable. The Basic solution space the I-D proposes doesn't include limiting what messages are signed by a domain. We've love to not sign spam at all, but short of never allowing users to send email, it's not actually possible. We're not trying to "accomodate sites that send spam", we're trying to minimise the blast damage of a message that a bad actor manages to get signed - because that reduces that value of getting such a message stamped with a signature, and that reduces the amount of spam. Still, knowing that he's a bad actor, you could skip signing. Are there so many new spammers every day? Or, rather, there is a bunch of professional spammers who know how to hide? How do you know he’s a bad actor before he does a bad action? That’s the crux of the problem: Very much agreed. the bad actor looks very much like a not-bad actor. You can’t generally tell the difference between the two until after the bad action has happened. In fact, the bad actor is often going to try and look as much like a not-bad actor as possible. That doesn’t mean they can’t be tracked. They are, and many of them get shut down based on patterns and vetting and a lot of things. Tracking and shooting down is good. However, as you note, it is not enough. How about enacting common sense rules such as Never sign anything without reading the small print? In the same way that users agree to any Terms & Conditions without reading, domains sign any mail their users send without knowing. Decadent practices, aren't they? Does Google know the real ID of its users? I'd guess in many cases they do; for example, Google does payments and bank stuff which do require real IDs (I pay, therefore I am). Nevertheless, they sign all email messages with the same d=gmail.com, irrespective of user reputation. I fully understand the right to anonymity. I know it's in the First Amendment, in the US. However, I figure users should trust their mailbox providers enough to disclose their real ID. The minority of people who really need to care about that can always find a provider in countries where ISPs cannot be forced to disclosure, or suffer sending lower grade mail. Would that be an acceptable kind of solution? But the reality is: bad-actors are going to get through every process. If we could ID spammers up front and stop them from spamming we’d very likely have done it already. In this case, they’re using DKIM in a way that was foreseen by the original authors but not treated as something that needed to be addressed in the protocol. Yes, replay was considered. Indeed, most protocol-change ideas being proposed these days turn out to have been already drafted at the time. Anyway, changing DKIM doesn't seem to be something that will have practical effects in the short and medium term. Consider ed25519, which is so straightforward to implement. Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
> On 15 Aug 2023, at 17:39, Dave Crocker wrote: > > On 8/15/2023 9:32 AM, Jim Fenton wrote: >> That isn’t quite fair. We thought about replay quite a bit, and didn’t see a >> viable way of addressing it. Your comment makes it sound like we didn’t care. > > To be a bit more thorough, my recollection is that we also did not expect it > to be a serious problem. I think we assumed that the re-posting and > re-delivery processes would entail enough control to stem that particular > tide. That is closer to my recollection of the discussion and the conclusion. But, again, for whatever reason it wasn’t something that was anticipated to be a big problem. > Kinder, simpler days. Very much so. laura (participating) -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On 8/15/2023 9:32 AM, Jim Fenton wrote: That isn’t quite fair. We thought about replay quite a bit, and didn’t see a viable way of addressing it. Your comment makes it sound like we didn’t care. To be a bit more thorough, my recollection is that we also did not expect it to be a serious problem. I think we assumed that the re-posting and re-delivery processes would entail enough control to stem that particular tide. Kinder, simpler days. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
> On 15 Aug 2023, at 17:32, Jim Fenton wrote: > > On 15 Aug 2023, at 5:59, Laura Atkins wrote: > >> But the reality is: bad-actors are going to get through every process. If we >> could ID spammers up front and stop them from spamming we’d very likely have >> done it already. In this case, they’re using DKIM in a way that was forseen >> by the original authors but not treated as something that needed to be >> addressed in the protocol. > > That isn’t quite fair. We thought about replay quite a bit, and didn’t see a > viable way of addressing it. Your comment makes it sound like we didn’t care. That wasn’t my intention and I apologize for coming across that way. laura (participating) -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On 15 Aug 2023, at 5:59, Laura Atkins wrote: > But the reality is: bad-actors are going to get through every process. If we > could ID spammers up front and stop them from spamming we’d very likely have > done it already. In this case, they’re using DKIM in a way that was forseen > by the original authors but not treated as something that needed to be > addressed in the protocol. That isn’t quite fair. We thought about replay quite a bit, and didn’t see a viable way of addressing it. Your comment makes it sound like we didn’t care. -Jim (one of the original authors) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
> On 15 Aug 2023, at 12:36, Alessandro Vesely wrote: > > On Tue 15/Aug/2023 08:10:23 +0200 Bron Gondwana wrote: >> "Problem solved." >> As someone who has, as a person running a service with a large number of >> customers who can send email, ... >> If you can provide me an accurate definition of spam which is not recipient >> specific and is actionable, I'd love to see it. Even if we could, >> theoretically, vet every single customer sufficiently to make sure they're >> all well behaved people who never send spam, the probability that we can >> also ensure that their accounts are never compromised, their devices are >> never compromised, such that they never send anything spammy. It's quite >> intractable, broad dismissive claims notwithstanding. > > I won't try a definition. However, I think it's easier to try a definition > of spammer. Probably we can stand the crowd of unintentional spammers whose > account or device was compromised, or who innocently tried to sell their > goods. There’s a lot of mail that can come out of a compromised account or device, so I’m not sure it’s something “we” can stand but I’m not sure that’s important. A compromised account can be shut down by the outbound sender. The device is harder - look at what’s going on with the IoT devices acting as open proxies / relays / sources of mail. But, in any case, that’s a different problem than what we’re dealing with here. > The bulk of actual spam is apparently authored by people who knows what > they're doing. Take this as a definition. Is it actionable? I do think we have to consider intent here. Replay spam, specifically, is intended to bypass anti-spam rules at the signing organization. The whole reason the mail is being signed by a reputable ESP but sent through a different infrastructure is because the reputable ESP will shut down the account. If we go old school: spam is the same thing many times. There was even an article written by someone who said they could ID forum spam even when they didn’t speak the language because it was the same thing repeated many times. (If it’s useful I’ll see if I can track that article down.) >> We've love to not sign spam at all, but short of never allowing users to >> send email, it's not actually possible. We're not trying to "accomodate >> sites that send spam", we're trying to minimise the blast damage of a >> message that a bad actor manages to get signed - because that reduces that >> value of getting such a message stamped with a signature, and that reduces >> the amount of spam. > > Still, knowing that he's a bad actor, you could skip signing. Are there so > many new spammers every day? Or, rather, there is a bunch of professional > spammers who know how to hide? How do you know he’s a bad actor before he does a bad action? That’s the crux of the problem: the bad actor looks very much like a not-bad actor. You can’t generally tell the difference between the two until after the bad action has happened. In fact, the bad actor is often going to try and look as much like a not-bad actor as possible. That doesn’t mean they can’t be tracked. They are, and many of them get shut down based on patterns and vetting and a lot of things. But the reality is: bad-actors are going to get through every process. If we could ID spammers up front and stop them from spamming we’d very likely have done it already. In this case, they’re using DKIM in a way that was forseen by the original authors but not treated as something that needed to be addressed in the protocol. I’ve been thinking about the description of a replay attack and how to describe it. I don’t like the wording here, but I think it might have legs conceptually. In a DKIM replay attack, the attacker sends filter evading mail through the victim domain for rebroadcast through infrastructure owned / controlled by the attacker. The outcome of the attack is that the good domain reputation of the victim domain results in better mail delivery for the attacker than using domains they own or control. There might be a plact, too, to describe the effects on the victims. Sender victims have mail they wouldn’t normally allow out in volume impact their reputation. Mailbox provider victims have their anti-spam defenses compromised. Individual user victims have more spam in their inboxes. laura (participating) -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
