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 is a bogus concept
On Thu, Aug 17, 2023, at 12:02 PM, Steffen Nurpmeso wrote: > More, usually (it happened in the past) they then point to their > web site, where you then *do*, and isn't the certificate of that > website, which itself is likely verified by some CA in some CA > pool that you do not have control over, or do not exert control > over, also because the interface is user unfriendly, a much bigger > problem, also security-wise, than the DKIM signature? Especially > with DNSSEC etc etc? If I understand correctly, there are some "no auth, no entry" requirements being suggested by some ISPs, in which they might start requiring DKIM signatures aligned to any/all domains in headers and body. I guess it's not enough that the web site has a CA cert, since those are trivial to obtain. So, now the CA problem shifts to DKIM. 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 is a bogus concept
Alessandro Vesely wrote in <652789f7-0a0a-f8db-11f9-2558bc9ec...@tana.it>: |On Thu 17/Aug/2023 04:45:48 +0200 Bron Gondwana wrote: |> On Tue, Aug 15, 2023, at 21:36, Alessandro Vesely wrote: |>> On Tue 15/Aug/2023 08:10:23 +0200 Bron Gondwana wrote: |>>> 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 \ ... |>> The whole concept of domain authentication is questionable if domains \ |>> have no |>> idea who their users are. |> |> At scale, there's always going to be a small percentage of bad users \ |> / hacked users on any system. Hence trying to make domain authenticatio\ |> n not so valuable that getting it on a message is super powerful. | |What is the value of domain authentication? And what should it be? | |To answer, consider you bought goods or services for a large amount. The |invoice arrives by email specifying the exact amount and the bank account \ |code. | The mail is DKIM-signed. Up to what amount would you trust and pay \ | without |calling? I think DKIM verifies source domains. That is a value by itself. With an extension it can also provide a locked contract about desired receivers; be made proof against malicious signature removals; and allow restoration of original content so that each modification can be undone; cryptographically secure from top to bottom. (If "from station to station" (the enhanced) DKIM is applied.) To answer your question. I do not yet pay digitally. I wonder whether we should start paying with salt again, or such. But if not, and if my bank (i have one) sends me a signed message, i think i would trust it. More, usually (it happened in the past) they then point to their web site, where you then *do*, and isn't the certificate of that website, which itself is likely verified by some CA in some CA pool that you do not have control over, or do not exert control over, also because the interface is user unfriendly, a much bigger problem, also security-wise, than the DKIM signature? Especially with DNSSEC etc etc? I personally do have my own $ env|grep SSL SSL_CERT_FILE=/home/steffen/sec.arena/tls.git/cacert.pem which derives from (what else?) (Google-paid) Mozilla, via (what else?) cURL mk-ca-bundle.pl, and is then adjusted a bit, automatically. However, i filter out some old stuff etc., i keep, and have to keep, of course, most of them in. This is all commercial, is it. (Now that the certificate of the Netherland was removed around December last year.) Very western stuff!! Unfortunately firefox does not pick that "standard" SSL_CERT_FILE up when it starts. :-( Heck i trust an unbelievable amount of someone because they paid for it! Compared with DKIM, where i put *my domain* into the DNS. Of course a service with billions of users has a problem. But the solution to that problem has, in my opinion, nothing to do with DKIM. And keys can always be stolen, no matter what service. And here i think DNS with its automatization and TimeToLive has a better stance than for example a billion local CA pools on this world. (Let aside that OCSP and rejection list verification are also often not used at all, or not up to date, etc.) --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 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 is a bogus concept
On Thu 17/Aug/2023 04:45:48 +0200 Bron Gondwana wrote: On Tue, Aug 15, 2023, at 21:36, Alessandro Vesely wrote: On Tue 15/Aug/2023 08:10:23 +0200 Bron Gondwana wrote: 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? The whole point is - you don't know that a stolen account is a bad actor before it starts sending messages, and the ability to tell that a single message is spam, when it's being sent to a single recipient - again, if you have a reliable definition I'd love to see it. Even something like `please click https://site.com/;>here to update your bank details`, real organisations send real email like that to their customers. You can't tell it's spam without context. Right, say you have to endure a replay attack only when an account is stolen. Would that diminish total replay attacks? I mean, how many replay attacks are instead committed using loosely verified accounts? Assuming one can verify the real ID of each account, that is. Whether that is feasible, expensive, convenient or ground-breaking is a different question. The whole concept of domain authentication is questionable if domains have no idea who their users are. At scale, there's always going to be a small percentage of bad users / hacked users on any system. Hence trying to make domain authentication not so valuable that getting it on a message is super powerful. What is the value of domain authentication? And what should it be? To answer, consider you bought goods or services for a large amount. The invoice arrives by email specifying the exact amount and the bank account code. The mail is DKIM-signed. Up to what amount would you trust and pay without calling? 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 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
