Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)
On Mon, Nov 28, 2022 at 9:16 AM Dave Crocker wrote: > I thought spammers varied in skills and dedication and that simple > mechanisms that blocked lazy spammers was generally viewed as being > useful. Apparently that has changed, and now all spammers are highly > skilled, dedicated and well-funded? > Nobody's opposed to simple mechanisms if they effectively address the problem. The issue is - while it's fairly trivial to replay a single signed message, it gets quite a bit more complicated to do it successfully at scale. So for our purposes, we've already eliminated the lazy spammers; what we need are techniques that are effective against sophisticated ones. This doesn't fit the bill. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
I support this. If the consensus is “that specific parts of the message have not been altered” should be added I’d support that, too. laura > On 28 Nov 2022, at 02:30, Murray S. Kucherawy wrote: > > Hi folks, > > Area Director hat on here: > > The discussion Barry kicked off has been interesting, but it has strayed (and > mea culpa, in part, because the material is interesting) from the work of > discussing a charter. > > I've set the stage for re-chartering in the system, and now we need some > charter text. Dave and Barry submitted text, which I've synthesized into > what's below. Let's keep this thread just to discussion the charter text; if > you want to continue to debate the technical solutions or problem space, > please start other threads or reply to the other existing ones. > > Here's my run at a charter; please provide suggestions or comments, or tell > us if you think it's ready to go. It's a variant of Barry's version with > parts of Dave's merged in. I've kept the list of candidate documents as a > starting point; the WG doesn't actually have to use any of them if that's > where consensus lands. > > But let's figure out consensus on a charter before we try to hammer out > consensus on solutions. > > -MSK > > -- > > Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for > using a digital signature to associate a domain identity with an email > message in a secure way, and to assure receiving domains that the message has > not been altered since the signature was created. Receiving systems > can use this information as part of their message-handling decision. > This can help reduce spam, phishing, and other unwanted or malicious > email. > > A DKIM-signed message can be re-posted, to a different set of recipients, > without > disturbing the signature's validity. This can be used to confound the > engines that > identify abusive content. RFC 6376 identified a risk of these "replay" > attacks, but > at the time did not consider this to be a problem in need of a solution. > Recently, > the community has decided that it has become enough of a problem to warrant > being revisited. > > The DKIM working group will produce one or more technical specifications that > describe the abuse and propose replay-resistant mechanisms that are compatible > with DKIM's broad deployment. The working group may produce documents > describing > relevant experimental trials first. > > Current proposals include the following drafts: > > - draft-bradshaw-envelope-validation-extension-dkim > - draft-chuang-replay-resistant-arc > - draft-gondwana-email-mailpath > - draft-kucherawy-dkim-anti-replay > > The working group may adopt or ignore these as it sees fit. > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)
On 11/28/2022 2:40 AM, Laura Atkins wrote: On 27 Nov 2022, at 18:48, Dave Crocker wrote: On 11/26/2022 5:38 PM, Jim Fenton wrote: Not Safe: It’s not safe because it breaks Barry’s use case above, and others have pointed out MUA usage of the signature. DKIM signature survival after delivery is not a goal for DKIM. If you feel otherwise, you are seeking an expansion of DKIM's purpose. This is actually the first I’ve heard this asserted. Do you have some history to back this up? Please see the later postings that discussed this. By way of example, open SMTP relays were deemed unacceptable. And they still are. Broadly speaking, having receivers remove the DKIM signature is a version of the same design thinking. Or perhaps you think open relays are ok, since, after all, attackers can easily circumvent this? This seems unreasonably snarky and a personal attack. The suggestion is for a small, simple, easily-adopted mechanism that closes off some venues from facilitating this form of abuse. Rather than consider it in those terms, it has engendered surprisingly vehement and problematic criticisms. This gets frustrating. The comparison to open relays is, IMO, appropriate. Consider the kinds of arguments against this proposal being applied to the suggestion to close open relays. One would wish for less heat and more thoughtful deliberation. We should move onto better ideas. Or, we might have thoughtful discussion, that engages carefully with the substance, before discarding suggestions. I’m not sure why you have settled on stripping the DKIM header as the solution, but it’s not going to be. It’s not even going to slow the folks using DKIM replay down (hint: most of the evidence I’ve seen shows that the attackers are ALREADY using their own MTAs to receive the emails). Multiple people have explained why this isn’t a solution. There’s no point in wasting time on a discussion. Let’s move on to something that will actually address the problem. I have not settled on the proposal as 'the' solution. I was clear about this. That you read otherwise demonstrates the problem with how the proposal is being dismissed out of hand. The other is the certitude of its uselessness. cf, open relays. [1] I’m not sure where or why this myth that “spammers won’t pay for anything” Since no one said any such thing, I don't know where the myth it has been said came from. and “a small incremental cost is sufficient to stop spammers from a particular technique” came from. I thought spammers varied in skills and dedication and that simple mechanisms that blocked lazy spammers was generally viewed as being useful. Apparently that has changed, and now all spammers are highly skilled, dedicated and well-funded? I’ve been on the phone with spam gangs who are spending tens of thousands a month on infrastructure and running custom code and doing BGP tricks to avoid port25 blocking and a whole host of other things that cost money, time and other resources. Probably a good thing, then, that there was no suggestion this proposal would stop all replay spammers. 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] Rechartering
On 11/28/2022 12:14 AM, Murray S. Kucherawy wrote: On Sun, Nov 27, 2022 at 6:50 PM Dave Crocker wrote: This does not provide any real understanding of how replay is accomplished. And since it's easy to explain and doesn't take much text, I'll again encourage including that in the document that defines the nature of the problem we will be working on, namely the charter. Doesn't the "A DKIM-signed message can be re-posted, ..." sentence do that? I pulled it from your suggested text for that very reason. Maybe add something to the second sentence making clear the roles in the attack? Your text: A DKIM-signed message can be re-posted, to a different set of recipients, without disturbing the signature's validity. This can be used to confound the engines that identify abusive content. If a reader is sufficiently knowledgeable and thoughtful, this text is probably sufficient. However... While a charter typically should not do deep tutorials, it does have a goal of being useful for a wide audience, such as helping to convince a manager that their company should participate. To that end, a bit of hand-holding in the charter can be helpful. * What does it take to achieve malicious reposting? Collaborating recipient. * How does this differ from non-malicious re-posting? Mostly it doesn't, except in scale of repostings. (And if I have that wrong, we should make sure we have solid wg understanding of the differences. And if there is not clear and immediate consensus about it, then developing it should be explicitly part of the charter, IMO.) * How does it 'confound' analysis engines? By using the reputation of a good source site and therefore by looking like it is legitimate. (Same parenthetical comments as the previous bullet.) Hence my text: A DKIM-signed message can be re-posted, to additional recipients, in a fashion that retains the original signature. With an author and a recipient collaborating, this can "replay" the message, using the original signer's reputation to propagate email with problematic content -- spam, phishing, and the like. Generally, the technical characteristics of this form of abuse match that of legitimate mail, making its detection or prevention challenging. Timestamps and carefully-tailored message signing conventions are appealing approaches to replay mitigation. Each has significant limitations. > The DKIM working group will produce one or more technical > specifications that > describe the abuse and propose replay-resistant mechanisms that are > compatible > with DKIM's broad deployment. The working group may produce documents > describing > relevant experimental trials first. This draft doesn't include the 'preservation of installed base' cover text that Barry's had and I forgot to include in mine. I think it's important. I had intended "compatible with DKIM's broad deployment" to cover exactly this. Should I word it differently? Looking over it less quickly, your text looks reasonable. However... Since this type of text is often important for controlling wg activity, I'll raise the question about the possible problem of having the wg decide that a significant change (not just addition) is needed that is NOT 'compatible'. Imagine something that is permitted now, but isn't used much, and creates problems. Making it no longer permitted might be helpful for dealing with the current problem, but, obviously, is not compatible with what is deployed, although actually affecting few activities. The challenge, then, is to document the goal of compatibility, without absolutely requiring it. Yours: The DKIM working group will produce one or more technical specifications that describe the abuse and propose replay-resistant mechanisms that are compatible with DKIM's broad deployment. Perhaps: The DKIM working group will produce one or more technical specifications that describe the abuse and propose replay-resistant mechanisms. The working group will seek compatibility with DKIM's broad deployment. 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] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)
> On 27 Nov 2022, at 18:48, Dave Crocker wrote: > > On 11/26/2022 5:38 PM, Jim Fenton wrote: >> Not Safe: It’s not safe because it breaks Barry’s use case above, and others >> have pointed out MUA usage of the signature. > > DKIM signature survival after delivery is not a goal for DKIM. If you feel > otherwise, you are seeking an expansion of DKIM's purpose. This is actually the first I’ve heard this asserted. Do you have some history to back this up? >> Not Effective: Attackers can easily circumvent this by running their own MX >> (if they don’t do that already) as Laura and others have pointed out. > > "Easily" is easy to say, but often difficult to measure or, at least, get > consensus on. > > The difference between being able to use an established receiving site, for > the conduct of the replay, versus having to have one's own receiving site, is > not zero expense or effort. A DKIM replay attack, in and of itself, is not zero expense or effort. The extra little bit of throwing up a postfix machine to receive one email is trivial in the whole process of standing up spam cannons. The amount of effort and expense professional spammers go to in order to get past filters is significant. [1] > By way of example, open SMTP relays were deemed unacceptable. And they still > are. Broadly speaking, having receivers remove the DKIM signature is a > version of the same design thinking. > > Or perhaps you think open relays are ok, since, after all, attackers can > easily circumvent this? This seems unreasonably snarky and a personal attack. >> We should move onto better ideas. > > Or, we might have thoughtful discussion, that engages carefully with the > substance, before discarding suggestions. I’m not sure why you have settled on stripping the DKIM header as the solution, but it’s not going to be. It’s not even going to slow the folks using DKIM replay down (hint: most of the evidence I’ve seen shows that the attackers are ALREADY using their own MTAs to receive the emails). Multiple people have explained why this isn’t a solution. There’s no point in wasting time on a discussion. Let’s move on to something that will actually address the problem. laura [1] I’m not sure where or why this myth that “spammers won’t pay for anything” and “a small incremental cost is sufficient to stop spammers from a particular technique” came from. It’s deeply wrong and misguided. I’ve been on the phone with spam gangs who are spending tens of thousands a month on infrastructure and running custom code and doing BGP tricks to avoid port25 blocking and a whole host of other things that cost money, time and other resources. -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On November 28, 2022 8:17:21 AM UTC, "Murray S. Kucherawy" wrote: >On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman >wrote: > >> I would add mention of the problem statement draft. I think it may turn >> out >> to be the most important of the ones we have now. >> > >Do you mean: Mention it as a mandatory deliverable? > >Should we still produce that document even if we conclude replay can't be >solved? I had been thinking about it as an input, since that document more fully describes the problem. > >> I still think "compatible with DKIM's broad deployment" is too narrow. >> Also, >> I think it's one reasonable conclusion the group might reach is that the >> cure >> is worse than the disease and a resolution along the lines of "remove >> signatures during delivery" and "be more careful about what you sign >> because >> signing bad things will hurt your domain's reputation" may be the most >> appropriate approach. >> > >Yes, I think it's always implied that a working group can throw in the >towel if consensus is to do that. I've never seen it spelled out in a >charter that this is an available option, but we can make it explicit if >people feel doing so would help set the scope. As long as there's a consensus in the group for a solution, even if it's not new protocol, I don't think that's giving up. If we quit because we can't reach rough consensus on a way forward, I think that could reasonably be characterized as throwing in the towel. > >> How about instead of "The DKIM working group will produce one or more >> technical specifications that describe the abuse and propose >> replay-resistant >> mechanisms that are compatible with DKIM's broad deployment" we say "The >> DKIM >> working group will evaluate potential mechanisms to mitigate this attack >> and >> produce one or more technical specifications that describe the abuse and >> propose improvements which, consistent with compatibility with DKIM's >> broad >> deployment and general email protocols, will reduce the impact of replay >> attacks". >> > >I think those say approximately the same thing, so I'm fine with either. > I agree it's not a large difference, but I'd prefer to be more explicit about general email compatibility. Thanks, Scott K ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman wrote: > I would add mention of the problem statement draft. I think it may turn > out > to be the most important of the ones we have now. > Do you mean: Mention it as a mandatory deliverable? Should we still produce that document even if we conclude replay can't be solved? > I still think "compatible with DKIM's broad deployment" is too narrow. > Also, > I think it's one reasonable conclusion the group might reach is that the > cure > is worse than the disease and a resolution along the lines of "remove > signatures during delivery" and "be more careful about what you sign > because > signing bad things will hurt your domain's reputation" may be the most > appropriate approach. > Yes, I think it's always implied that a working group can throw in the towel if consensus is to do that. I've never seen it spelled out in a charter that this is an available option, but we can make it explicit if people feel doing so would help set the scope. > How about instead of "The DKIM working group will produce one or more > technical specifications that describe the abuse and propose > replay-resistant > mechanisms that are compatible with DKIM's broad deployment" we say "The > DKIM > working group will evaluate potential mechanisms to mitigate this attack > and > produce one or more technical specifications that describe the abuse and > propose improvements which, consistent with compatibility with DKIM's > broad > deployment and general email protocols, will reduce the impact of replay > attacks". > I think those say approximately the same thing, so I'm fine with either. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On Sun, Nov 27, 2022 at 6:50 PM Dave Crocker wrote: > On 11/27/2022 6:30 PM, Murray S. Kucherawy wrote: > > Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for > > using a digital signature to associate a domain identity with an email > > message in a secure way, and to assure receiving domains that the > > message has > > not been altered since the signature was created. Receiving systems > > Again: DKIM does not assure that the message has not been altered. It > assures only the covered portions of the message. > > That's not a small difference in data integrity protection. > OK, I'll add that in. > > A DKIM-signed message can be re-posted, to a different set of > > recipients, without > > disturbing the signature's validity. This can be used to confound the > > engines that > > identify abusive content. RFC 6376 identified a risk of these > > "replay" attacks, but > > at the time did not consider this to be a problem in need of a > > solution. Recently, > > the community has decided that it has become enough of a problem to > > warrant being revisited. > > This does not provide any real understanding of how replay is > accomplished. And since it's easy to explain and doesn't take much > text, I'll again encourage including that in the document that defines > the nature of the problem we will be working on, namely the charter. > Doesn't the "A DKIM-signed message can be re-posted, ..." sentence do that? I pulled it from your suggested text for that very reason. Maybe add something to the second sentence making clear the roles in the attack? > > The DKIM working group will produce one or more technical > > specifications that > > describe the abuse and propose replay-resistant mechanisms that are > > compatible > > with DKIM's broad deployment. The working group may produce documents > > describing > > relevant experimental trials first. > > This draft doesn't include the 'preservation of installed base' cover > text that Barry's had and I forgot to include in mine. I think it's > important. > I had intended "compatible with DKIM's broad deployment" to cover exactly this. Should I word it differently? -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
