Re: [Ietf-dkim] DKIM Signature
> On 31 Oct 2023, at 00:26, Steffen Nurpmeso wrote: > > > |4. I don't understand how that is relevant to the current working group > |topic of a problem statement > > (that is what the thread is about) There is nothing in the current problem statement that is discussing changing the algorithm or adding another algorithm. I am not clear on how changing the algorithm addresses the DKIM replay problem. Can you explain to us how this will address the issue the group is currently chartered to address? 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] DKIM Signature
I do appreciate the discussion here, but the current issue we’re trying to address is the problem statement. laura > On 29 Oct 2023, at 12:12, John R Levine wrote: > >> Future proofing? The history of encryption is riddled with examples of >> overconfidence. > > Well, sure, and I would not be opposed to revisiting this issue in a decade. > > As Scott noted, approximately nobody handles ed25519 yet, and nobody will > until there is some reason to believe that RSA signatures are too weak. > Adding another five tons of steel to the door won't change that. > > And on the third hand, if something unexpected happens and RSA and ed25519 > both fail, why do you imagine Ed448 wouldn't fail too? If someone figures > out how to make large quantum computers, they're all toast and we'll have to > switch to PQC. > > R's, > John > >> On Fri, Oct 27, 2023 at 2:02 PM John Levine wrote: >> >>> It appears that Scott Kitterman said: >>>> On October 27, 2023 2:56:30 PM UTC, "Murray S. Kucherawy" < >>> superu...@gmail.com> wrote: >>>>> On Sun, Oct 1, 2023 at 1:50 AM Jan Dušátko >> 40dusatko@dmarc.ietf.org> >>>>> wrote: >>>>> >>>>>> I would like to ask to consider the possibility of defining a DKIM >>>>>> signature using Ed448. [...] >>> >>>> My view is that more encryption algorithms are bad for interoperability. >>> For DKIM signing/verifying to work, senders >>>> and verifiers need a common algorithm. More choices make this more >>> complex to achieve. >>>> >>>> We standardized ed25119 as a hedge against unknown vulnerability in RSA. >>> ... >>> >>> Since we already have ed25519, why would we want ed448? If ed25519 is a >>> ten ton steel >>> door on our cardboard box, ed448 is a fifteen ton steel door. >>> >>> R's, >>> John >>> >>> ___ >>> Ietf-dkim mailing list >>> Ietf-dkim@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-dkim >>> >> > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim -- 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] What makes this posting different from the original posting?
> On 1 Sep 2023, at 18:31, Grant Taylor > wrote: > > On 9/1/23 3:32 AM, Laura Atkins wrote: >> You don’t know that they don’t do spamfiltering on outbound messages. You >> don’t see what they catch and don’t send. What you do see is when that spam >> filtering fails. > > I do know that a small number of operators don't do any outbound spam > filtering because it has come up in conversations comparing systems / > configurations. Are those operators being targeted with replay attacks? if they’re not, I don’t think this discussion is really relevant to the group. laura (participating) > >> Many ESPs are doing that, and doing blocklist checking on URLs. > > I'm glad for the ESP's efforts. > > I wish more people would do so. > >> But all it takes is for one message to slip through and amplified. > > I'm not talking about the false positives / false negatives. > > I'm talking about the lack of any outbound filtering period. Not what slips > through said filtering. > >> I don’t understand how this is going to address the problem. > > It won't solve the problem. No single thing will solve the problem. > > But it's another simple test that can be done between the MSA and the MTA to > reject things early in the flow. > >> As Bron said: the inbound system has a lot more information about the mail >> than the outbound system. > > Having more or less information doesn't have anything to do with acting on > the information that you do have, especially if it's verifiable and reliable. > >> I’ll also point out that if it’s one-to-one or one-to-few there are >> legitimate reasons to send spam. Say, mail to an abuse address reporting >> spam. I’m sure we can agree that MTAs shouldn’t be blocking abuse reports, >> yes? What you’re asking for means a lot of spam reports will be blocked (or >> incomplete). > > I'm trusting that's not a "but think of the children" knee jerk response > along the lines of "we can't filter outbound spam because we want to not > block spam reports." > > There's reasonable basic filtering and then there's deep filtering. > > I'm sure that we all know what we need to do t in order to get spam reports > through our respective systems. > > 1) Try forwarding spam as a message/rfc822 attachment. > 2) Try forwarding spam headers as a text/rfc822-headers attachment. > 3) Try putting #1 in a zip file. > 4) Try putting #2 in a zip file. > 5) Try password protecting #3. > 6) Try password protecting #4. > ... > n) Ask your postmaster how you are supposed to report spam. > > I maintain that basic spam and virus filtering should be done on outbound > email. > >> You’re asserting there are no basic checks being done. Do you have any >> evidence other than sometimes mail evades the outbound filters? > > I have had conversations with multiple small email operators over the years > that have told me that they only do any spam and virus filtering on inbound > email and that they do not do any such filtering on outbound email. > > > > -- > Grant. . . . > unix || die > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim -- 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] What makes this posting different from the original posting?
> On 1 Sep 2023, at 03:49, Grant Taylor > wrote: > > On 8/31/23 8:02 PM, Bron Gondwana wrote: >> The classic case was that spam about V*gra was very common, but blocking >> that word in every anti-spam filter would create something that was really >> not fit for purpose for Pfizer to use for their email system. The sender >> and recipient really make a difference about what is spam - and as the >> sender you don't know who the end recipient is, because there are plenty of >> recipients. > > I've seen -- what I consider to be -- too many systems -- read more than zero > -- that apply some amount of spam filtering to inbound message and no spam > filtering on outbound messages. You don’t know that they don’t do spamfiltering on outbound messages. You don’t see what they catch and don’t send. What you do see is when that spam filtering fails. > I've also seen many of these systems wonder why they ended up black listed > when an account was compromised and someone was sending spam through said > system. > > I feel like there should be basic spam filtering on outbound messages. Even > if it's as simple as logistical checks; making sure the from makes sense, > probably running the message through something like a default configuration > of SpamAssassin (without Bayes), and probably through something like ClamAV. > Just basic sanity checking on messages. Many ESPs are doing that, and doing blocklist checking on URLs. But all it takes is for one message to slip through and amplified. > Dare I say, I'd add SPF between the MSA and MTA. I don’t understand how this is going to address the problem. > Things to prevent blatant spam / viruses much closer to the -- likely to be > authenticated -- sender. > > I'll say it this way, if there's a 90% chance that your inbound system would > block it, then why should your outbound system send it? As Bron said: the inbound system has a lot more information about the mail than the outbound system. I’ll also point out that if it’s one-to-one or one-to-few there are legitimate reasons to send spam. Say, mail to an abuse address reporting spam. I’m sure we can agree that MTAs shouldn’t be blocking abuse reports, yes? What you’re asking for means a lot of spam reports will be blocked (or incomplete). >> Fact: recipient spam filter has more information than sender spam filter >> Result: recipient spam filter can be more restrictive without causing excess >> damage. > > Yes, there is different data. > > But there is still data on the sending side that can be used to perform basic > checks. You’re asserting there are no basic checks being done. Do you have any evidence other than sometimes mail evades the outbound filters? >> There's no hypocrisy in recognising the asymmetry, and designing with that >> in mind. > > I still think that it's hypocritical to have zero spam filtering on outbound > email while having any spam filtering on inbound email. 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] What makes this posting different from the original posting?
> On 30 Aug 2023, at 14:52, Grant Taylor > wrote: > > On 8/30/23 12:35 AM, Murray S. Kucherawy wrote: >> And I've never understood why people get enamored of the idea of relying on >> bad reputations to spot bad actors. > > I think of it as the other way around; good reputation to spot good actors. > > Much like a brand new domain is effectively neutral immediately after it's > created. Said domain earns a reputation either good or bad over time. In reality “new” domains are actually treated more negatively than neutral in many circumstances. -- 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] What makes this posting different from the original posting?
> On 29 Aug 2023, at 19:07, Dave Crocker wrote: > > Not that this is all that new a question, but I think it might be worthy of > more (and maybe different focus)... > > When a message is used in a DKIM Replay Attack: > > It originates from a domain name having good reputation > It passes quality checks from that sending domain > It goes to a collaborating receiving site, which presumably means that site > is not conducting quality assessments > It is re-posted, preserving the original DKIM signature, but now becomes an > attack > Two thoughts: > > If the substance of the message should fail a quality assessment, why does it > pass at the outbound (sending) site? Spam isn’t really about substance, though, it’s about being unwanted and volume. A lot of things outbound folks use to identify spam require volume - like ‘is this audience similar to the audience we’ve seen report high levels of spam in the past’ or ‘does this send to addresses we know receive a lot of spam’ or ‘is this account sending to a lot of bad addresses’. There are other checks, like ‘does this email contain a link pointing to a hostname on any of these DNSBLs’ - but that’s trivially solved by just pulling out a link that isn’t on a DNSBL. The professional spam gangs, who are likely behind the attacks, have a deep bench of domains that they pull in and out of circulation on a regular basis. This also doesn’t address the problem that Google mentioned where they saw Youtube alerts / welcome messages replayed, possibly as a way to create a good IP reputation. > If the problem is reasonable content, but sent to many unintended (or, > rather, undeclared) recipients, then the only characteristic of note is the > fact of multiple transmissions. So I'd guess it is only a real-time network > of receivers, working in /very/ close coordination, to detect and deal with > the attack. (it's not difficult to imagine scattered retransmissions, over > time, to hide the coordination. Sort of a spread spectrum transmission > style...) My understanding is that one of the primary ways to ID a replay is using Google postmaster tools and seeing increases in their graphs without a corresponding increase in volume from their systems. laura -- 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 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 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 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 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 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
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
> On 9 Aug 2023, at 15:55, Murray S. Kucherawy wrote: > > On Wed, Aug 9, 2023 at 2:54 AM Laura Atkins <mailto:la...@wordtothewise.com>> wrote: >> If there are multiple BCCs that implies that whatever is creating the mail >> must make individual copies of the message with only the BCC recipient in >> that line before it’s signed with DKIM. So for a message with 3 BCCs, there >> are 4 separate copies of the message to be created, one with no BCC header >> and 3 for each of the BCC recipients. Then each message must be individually >> signed. >> >> I’m not sure how that’s going to work in practice. > > I have heard, but have not verified, that some MLMs do this > one-recipient-per-copy thing already, despite RFC 5321 encouraging the > opposite. If true, I don't know whether this was done to allow per-instance > signing or because it allows for better tracking and association of bounces, > or for some other reason. It occurs to me that unless the Date field changes > for each instance, the DKIM signature would be the same for each instance > anyway. The one per copy is mostly VERP (https://en.wikipedia.org/wiki/Variable_envelope_return_path) related but the signatures should be the same for every message. When we’re signing a field that changes per message, that’s a different situation. > However, if it is already the case that MLMs generally produce a copy per > recipient, then any Bcc scheme would work, and much of the fragility with the > "include the recipient in the signature" approach vanishes. I wasn’t actually thinking about MLMs. I was more thinking about the “normal” case of one-to-few emails. BCC is widely recommended and used in situations where there’s intimate partner abuse as a way to document interactions with the abusive partner. That was, honestly, the situation I was envisioning. What happens if the abusive partner discovers the BCC address because there’s a problem with the code that’s managing the signing? It’s probably much easier to cope with in terms of the MLM code base than the non-bulk code base. But that still brings up the challenges of what recommendations do we make for messages that don’t have a BCC header field? Or can we just recommend that the MLMs and bulk sender software sign a blank BCC field? 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] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
> On 6 Aug 2023, at 19:07, Jesse Thompson wrote: > > On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote: >>> On 5 Aug 2023, at 02:43, Jesse Thompson >> <mailto:z...@fastmail.com>> wrote: >>> >>> On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote: >>>> I agree with this and have been working to recruit folks to come here. >>>> I’ll also be in Brooklyn and pitching the need for participation in the >>>> IETF working group from folks in the email space who are seeing issues >>>> with this. >>> >>> I'll be there and interesting in participating. As an ESP/infrastructure >>> provider I can say that we are "having" the issue, but can't say that we >>> "seeing" the issue since visibility is only available to anti-spammers, and >>> domain owners (who receive DMARC reports). >> >> A big driver of the work is actually Google. As I understand it, they are >> having issues because the replay attackers are successfully stealing >> reputation of otherwise good senders in order to bypass some spam filtering. >> The replay attackers aren’t sending what we commonly think of as spam >> through the signers - as the message is sent to one recipient (not bulk) and >> it is opt-in (that recipient wants and has asked for the mail). > > This is accurate from my observation. It takes only a single message which > evades content filters, and the attacker is the first recipient, who will not > report it as abuse. > > Which is why an earlier "just don't send spam" comment seemed to be > borderline FUSSP rhetoric. If the message isn't detected by the receiver (who > has the most visibility into the type of mail its users want to receive) then > how can a sender be held to a higher standard of detection with less > visibility? I agree wholeheartedly. I just wanted to make it clear for the record that this isn’t an issue of the signer knowingly signing spam and “deserving” any reputation problems. > The reputation they are stealing is that of the DKIM domain(s) associated > with the signatures on the message (whether they are aligned to the > rfc5322.From or not). So, adding more signatures to convey more fidelity > would seemingly help solve the problem because receivers could better > fingerprint good patterns from bad patterns. But replayers could just remove > the higher fidelity signatures. > > To solve that, I think we need Mandatory Tags for DKIM Signatures [1] 3.3. > Forward signature (!fs) tag. > > [1] https://datatracker.ietf.org/doc/html/draft-levine-dkim-conditional-04 > 3.3. Forward signature (!fs) tag > The "!fs" mandatory tag means that the signature is only valid if an > additional signature is present in the message. The value of the !fs tag is a > domain name that is the value of the d= tag of the additional signature. The > condition is satisfied if the message includes at least one valid DKIM > signature header field with responsible domain (the d= tag) being one > specified by the !fs tag. Chained !fs tags are valid and may be useful in > scenarios with multiple levels of forwarders. DKIM verifiers SHOULD handle at > least three levels of !fs chaining. I’ll have to read that more fully, but a brief read through seems to indicate this isn’t the solution to the replay problem. To whit: "6. Security Considerations It opens up a variety of obvious replay attacks that may or may not be important depending on both the selection of target domains for messages to be forwarded, and the behavior of forwarders that receive messages with conditional signatures.” Also, I’m not sure how it will work on mail that isn’t expected to be forwarded. >>> I recall various assertions that the reason why DMARC has been successful >>> is primarily because of the Reporting benefits (and I certainly agree with >>> this assertion from my background as an enterprise domain owner), while the >>> Conformance benefits seem to be more elusive (as evidenced by the >>> inconsistent adoption by receivers and the debates around interoperability >>> issues with indirect mail streams). Of course, the Authentication benefits >>> are provided by DKIM/SPF, and yet DKIM signers have no standard mechanism >>> to receive reports of how their signatures are being misused. >>> >>> If people think that Reporting is the reason why DMARC has been successful, >>> then could we conclude that the lack of Reporting to DKIM signers is a >>> problem worth addressing? >> >> That’s an interesting thought. I’m thinking the next step down - will it >>
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
> On 5 Aug 2023, at 02:43, Jesse Thompson wrote: > > On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote: >> I agree with this and have been working to recruit folks to come here. I’ll >> also be in Brooklyn and pitching the need for participation in the IETF >> working group from folks in the email space who are seeing issues with this. > > I'll be there and interesting in participating. As an ESP/infrastructure > provider I can say that we are "having" the issue, but can't say that we > "seeing" the issue since visibility is only available to anti-spammers, and > domain owners (who receive DMARC reports). A big driver of the work is actually Google. As I understand it, they are having issues because the replay attackers are successfully stealing reputation of otherwise good senders in order to bypass some spam filtering. The replay attackers aren’t sending what we commonly think of as spam through the signers - as the message is sent to one recipient (not bulk) and it is opt-in (that recipient wants and has asked for the mail). > I recall various assertions that the reason why DMARC has been successful is > primarily because of the Reporting benefits (and I certainly agree with this > assertion from my background as an enterprise domain owner), while the > Conformance benefits seem to be more elusive (as evidenced by the > inconsistent adoption by receivers and the debates around interoperability > issues with indirect mail streams). Of course, the Authentication benefits > are provided by DKIM/SPF, and yet DKIM signers have no standard mechanism to > receive reports of how their signatures are being misused. > > If people think that Reporting is the reason why DMARC has been successful, > then could we conclude that the lack of Reporting to DKIM signers is a > problem worth addressing? That’s an interesting thought. I’m thinking the next step down - will it help minimize the problem for senders? ie, would reporting be fast enough that they could revoke a key? What might a report look like? laura -- 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] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
> On 3 Aug 2023, at 16:44, Barry Leiba wrote: > >> A point I was trying to make in earlier posts is that this topic does >> not seem to me to warrant anything close to that much effort on >> producing background text. >> >> Especially when we so far seem to be lacking cohesive effort to >> formulate serious technical and operational 'solutions' and the >> community support to field them. >> >> We need a lot more focus on the recruiting industry >> support/participation and on formulating technical specifications that >> will be used. > > This I completely agree with: we saw a great deal of interest from > M3AAWG about this, and the discussions there led to discussions here > that got this working group started. But since then we've seen no > apparent interest in following through, apart from the few who > actively drove the chartering. I agree that we need to see broader > interest in working on solutions and broad assurance that those > solutions will be implemented. There's been talk about having a > session at the October M3AAWG meeting in New York, and I'll be > interested to see what results from that. I agree with this and have been working to recruit folks to come here. I’ll also be in Brooklyn and pitching the need for participation in the IETF working group from folks in the email space who are seeing issues with this. 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] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
> On 1 Aug 2023, at 17:00, Dave Crocker wrote: > > On 8/1/2023 8:56 AM, Barry Leiba wrote: >> The eventual product should point back to the problem statement for >> the background information. > > That is certainly a valid approach. However I suggest it's less efficient > for this topic and possibly will lose some casual readers of the spec, by > virtue of the indirection. (Extra clicks cost usability.) I’m not sure this is a problem, actually. It’s likely we’ll lose those casual readers anyway, if they’re bogged down in background information. > I suggest, instead, whatever spec is produced have a statement of the > problem. This is a relatively simple problem to explain. No doubt the text > will be drawn from this draft. Of course the spec will have a statement of the problem. The question here is: how much does the spec focus on the spec vs. how much does it discuss all the examples and data about why we got to this as the spec. I think that the why, condensed down in a supporting document, is valuable. I think, though, that as part of the spec it’s a distraction. 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] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
I actually think this is a good approach and works well within the charter that we have for the group. Put together a background document - that evolves from the problem statement including all the pieces that you mentioned * problem description * why this wasn’t solved initially * real world scenarios where this happens and some of the consequences of it backed by actual data * what has been tried and hasn’t worked (with some discussion of why it didn’t work) * what we considered and rejected In fact, I think that’s one of the legitimate outcomes of the group from the re-charter (https://datatracker.ietf.org/wg/dkim/about/): "If the working group decides that is unable to identify a consensus technical solution to this problem space, it may instead publish a report describing the problem and summarizing the reasons that none of the proposed approaches are acceptable.” laura (as participant) > On 1 Aug 2023, at 19:40, Barry Leiba wrote: > > As someone who has, as an AD, questioned the publication of such > background documents, even in working groups I chartered, I can give a > related opinion about this one: > > I do think the background is important to publish separately for this > work, however easy the problem is to describe. I think it's important > that those interested have access to the problem description, reasons > that it wasn't solved in the original DKIM specification, things that > people have tried and that didn't work, and things that we have > considered and rejected, and any other such background that got us to > where we are now and that eventually gets us to what we propose, if, > indeed, we wind up proposing anything. And I think it's important > *not* to put that into any protocol proposal that we make, so as to > keep that specification clean and concise. > > Yes, we *could* put it into a protocol document as an appendix, but I > think in this case it could be longer than the protocol description > and will likely bloat the document and be distracting. I would rather > see something that that gives a one-paragraph summary of what we're > solving, a reference to the document with the broader background, the > proposed solution, and whatever limitations and cautions we see for > that solution. > > That said, this'll be my last opinion on that point, as I don't think > it's worth a great deal of debate and I'm happy to accept whatever > consensus we wind up with. Better to spend the effort on the > solution. > > Barry > > On Tue, Aug 1, 2023 at 1:30 PM Murray S. Kucherawy > wrote: >> >> On Tue, Aug 1, 2023 at 8:29 AM Laura Atkins wrote: >>> >>> We have a current version of the draft problem statement available on the >>> data tracker. Murray and a few others made a few comments that were added >>> in the -03 version. >>> >>> >>> https://mailarchive.ietf.org/arch/msg/ietf-dkim/Q5ybHiYkMlg5QFaFp28Y8uSme1Q/ >>> >>> >>> Based on discussions, there seems to be favor to documenting what has been >>> tried and not worked. >>> >>> >>> Question for the working group: Should the discussion of what hasn’t worked >>> be in the problem statement as an Appendix? Or should it be in a separate >>> document as working group output? >>> >>> >>> Along the same lines, do members of the working group feel we should >>> include some of the solution space in the problem statement? Or should the >>> discussion be reworked? >>> >>> >>> Perhaps instead of "possible solution space" maybe "scenarios and how they >>> affect dkim replay" ? We welcome any suggestions of wording changes. >> >> >> I just did an informal poll of the IESG members that happened to be active >> in the IESG slack channel at the time I asked. >> >> There's a previous IESG statement on this topic that's relevant: >> https://www.ietf.org/about/groups/iesg/statements/support-documents/ >> >> Generally, this informal poll suggests the IESG disfavors a document that is >> nothing more than a problem statement. This aligns, unsurprisingly, with >> the IESG statement. Such documents, by themselves, have uncertain archival >> value. So if we want to publish a problem statement, with or without a >> "what we've tried" appendix, we should consider merging the proposed >> solution(s) into such a document before advancing it to the IESG. >> >> -MSK, ART AD >> ___ >> Ietf-dkim mailing list >> Ietf-dkim@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-dkim -- 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
[Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
Hi, All, We have a current version of the draft problem statement available on the data tracker. Murray and a few others made a few comments that were added in the -03 version. https://mailarchive.ietf.org/arch/msg/ietf-dkim/Q5ybHiYkMlg5QFaFp28Y8uSme1Q/ Based on discussions, there seems to be favor to documenting what has been tried and not worked. Question for the working group: Should the discussion of what hasn’t worked be in the problem statement as an Appendix? Or should it be in a separate document as working group output? Along the same lines, do members of the working group feel we should include some of the solution space in the problem statement? Or should the discussion be reworked? Perhaps instead of "possible solution space" maybe "scenarios and how they affect dkim replay" ? We welcome any suggestions of wording changes. laura -- 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] Moving forward - from the chairs
> On 10 Apr 2023, at 19:38, Murray S. Kucherawy wrote: > > On Mon, Apr 10, 2023 at 11:24 AM Scott Kitterman <mailto:ietf-d...@kitterman.com>> wrote: >> On Monday, April 10, 2023 2:05:28 PM EDT Laura Atkins wrote: >> ... >> > There is currently an active Call for Adoption for a draft. >> ... >> >> What's the plan for closing this out? I haven't seen any objections to the >> idea and as of tomorrow it will have been over a week since the formal call >> for adoption. This happens rarely enough in my experience that I don't >> recall >> how long these normally run. > > Usually a week or two. The original post wasn't specific, so at this point I > think the chairs could call consensus at their discretion unless someone > wants to argue it should stay open longer. > > The datatracker normally asks what the CFA duration is, but in the "History" > tab for this document it doesn't look like one was recorded. Might be > something for the tools team to look at. I set it for 3 weeks when I set it up in the datatracker. I think it’s worthwhile to give folks a chance to weigh in. laura -- 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
[Ietf-dkim] Moving forward - from the chairs
Hello, all === From Laura Thank you for your patience with getting this working group off the ground. As Murray said I am a new chair and I am still learning IETF processes. When Murray asked if I would chair the group, I agreed but requested an experienced IETF chair to co-chair the group and Tim agreed. Both Murray and Tim were at the meeting in Yokohama and had significant time commitments but still found time to answer questions and work with me. I want to thank both of them for their guidance and assistance. === From Laura and Tim In terms of where we’re going from here, the chairs have negotiated a milestone shift to give us a little more space to get the problem statement finished. There is currently an active Call for Adoption for a draft. As Barry and others have pointed out, this draft is a starting point, not the final problem statement. We hope to use the extra time to refine and improve the problem statement to address the concerns that the current text is too vague. In parallel, with the Call for Adoption and working on the language to include in the problem statement, we would also like to hear from operators with experience in the specific techniques of DKIM replay attacks. This includes operators who have had their DKIM d= used in a replay attack and operators who have been sent mail as part of a replay attack. We do want to remind people that individuals, not groups, participate in IETF working groups. The DKIM replay issue is a problem that has been discussed in other industry groups. Some of the participants here are also present in those groups. We welcome participation from people who have experience with the issue and encourage them to share that information here. Thank you again for your patience and participation Laura and Tim, as chairs -- 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
[Ietf-dkim] Call for adoption
I want to thank everyone for their patience as I learn IETF processes and tools. Tim and I are working on a statement for the group from us as chairs. While we’re doing that, though, I would like to get the group moving forward and get some text adopted. I have issued a Call for Adoption for Wei’s draft so that we have text to work with and on. The list is still on moderation status but we will be approving posts. laura -- 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] What has been tried and doesn't work should be documented in the problem statement
You are correct and I apologize. I did send a message, but your address was omitted from the to: list. That is my error and I am very sorry. I will forward you a copy of the message you should have received offlist. As for the rest, both Murray and Tim are participating in IETF 116 at the moment. I have been in contact with Murray throughout this process and have taken the actions I have with his guidance and approval. Again, I apologize that I was not careful in sending the email yesterday and left your address off the cc list. laura > On 28 Mar 2023, at 19:34, Michael Thomas wrote: > > > > On 3/28/23 2:31 AM, Laura Atkins wrote: >> Dear Michael, >> >> Your message of 27 March quoted in its entirety below, included _ad hominem_ >> attacks against another participant. _Ad hominem_ is a fallacious form of >> argument wherein the person arguing attacks the person holding an opposing >> position, rather than attacking the position itself. This is not >> acceptable, and you have been warned before. I contacted you off-list on >> behalf of the chairs, under the procedures in BCP 25, but you have refused >> to take what we regard as rectifying action. > I have not been contacted off-list. Surely you can produce evidence. It is > not in my spam folder either. > > > Mike > > -- 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] What has been tried and doesn't work should be documented in the problem statement
Dear Michael, Your message of 27 March quoted in its entirety below, included _ad hominem_ attacks against another participant. _Ad hominem_ is a fallacious form of argument wherein the person arguing attacks the person holding an opposing position, rather than attacking the position itself. This is not acceptable, and you have been warned before. I contacted you off-list on behalf of the chairs, under the procedures in BCP 25, but you have refused to take what we regard as rectifying action. Accordingly, please understand this message as a formal warning under the procedures of BCP 25 that, if we observe continued behaviour of the sort you have exhibited, we shall suspend your posting privileges to the dkim-ietf mailing list for 30 days. Behaviour of the sort includes anything that we believe to be needlessly personalized, and especially includes _ad hominem_ forms of argument. We will also treat returning to points that have been closed without raising new arguments as attempts to disrput the functioning of the Working Group. We will act without further warning in such an event. If we take that action, and, after restoration of your privileges, we observe you to return to disrupting the work of the group, we shall undertake action under BCP 25. Sincerely, Laura (for the chairs) > On 27 Mar 2023, at 17:04, Michael Thomas wrote: > > > On 3/27/23 8:46 AM, Scott Kitterman wrote: >> >> On March 27, 2023 3:10:40 PM UTC, Laura Atkins >> wrote: >>> >>> It seems to me a history of what did work / didn’t will go into document 4 >>> or the reasoning for document 3. My current preference is for the >>> discussion to not be in the problem statement. My reasoning is that there >>> will be discussion about what didn’t work and why it didn’t work. I expect >>> that there will be quite a bit of back and forth to capture the details of >>> why something didn’t work - including the adaptations that the attackers >>> made to the changes. This, to my mind, is the job of the working group: to >>> look at the current status, discuss where the holes are and if they are >>> protocol holes or if they are best practice / implementation holes. >>> >>> On a more practical point, we have a month to finalize the problem >>> statement. No one has proposed language to include in the problem statement >>> about what has worked and what hasn’t worked. Given the current state of >>> the group, I simply don’t think we have the time to put this into the >>> problem statement and get it out in time. >>> >>> I do think we have the time and space to discuss techniques after the >>> problem statement is done and include it in one of the WG output documents. >>> >> So far, unless I was napping when it happened, we don't have a working group >> draft of the problem statement. > > Exactly. It's rather disingenuous to require people to propose text to a > non-working group document especially since we don't know what is going to be > in a next version since it doesn't have to track the consensus of the working > group. > > Also: it's disingenuous to demand text for something that the scope has not > even been established. It also assumes that we know the answers which we > don't. My post was trying to get some of those answers but it wasn't enough, > and may well have missed many pertinent things since I'm not an industry > insider. The intent of my questions was start an inquiry into that state that > could be used as input. > > Lastly: cutting off debate because of time is bogus. Murray already said that > the milestone dates were fairly arbitrary. Using them as a tool to get the > chair's preferred result is... disingenuous. > > Mike > > ___ > 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] What has been tried and doesn't work should be documented in the problem statement
Sent from my iPhone > On Mar 27, 2023, at 6:40 PM, Scott Kitterman wrote: > > On Monday, March 27, 2023 12:42:25 PM EDT Laura Atkins wrote: >>>> On 27 Mar 2023, at 16:46, Scott Kitterman wrote: >>> >>> On March 27, 2023 3:10:40 PM UTC, Laura Atkins > wrote: >>>>> On 26 Mar 2023, at 11:13, Murray S. Kucherawy >>>>> wrote: >>>>> >>>>> On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas <mailto:m...@mtcc.com>> wrote: >>>>>> On 3/24/23 6:19 PM, Barry Leiba wrote: >>>>>>> I don't agree with the premise. I think what was tried and didn't >>>>>>> work should be documented in the result that the working group comes >>>>>>> out with, but not in the problem statement. >>>>>> >>>>>> There isn't a place in the charter/milestones for that. >>>>> >>>>> The charter identifies these possible outputs in some combination: >>>>> >>>>> (1) a clear problem statement; >>>>> >>>>> (2) one or more protocol update document(s); >>>>> >>>>> (3) a statement of some kind that the WG determined no feasible protocol >>>>> solution exists (and, one would hope, how it reached this conclusion); >>>>> >>>>> (4) an update to current DKIM operational advice with respect to the >>>>> stated problem. >>>>> >>>>> The only constraint in the charter is that (2) and (3) are mutually >>>>> exclusive.>> >>>> Agreed with all of this. >>>> >>>>> I believe that a history of what techniques were previously tried and >>>>> failed could arguably go into any of them. The charter is neither >>>>> prescriptive or proscriptive on this point.>> >>>> It seems to me a history of what did work / didn’t will go into document >>>> 4 or the reasoning for document 3. My current preference is for the >>>> discussion to not be in the problem statement. My reasoning is that >>>> there will be discussion about what didn’t work and why it didn’t work. >>>> I expect that there will be quite a bit of back and forth to capture the >>>> details of why something didn’t work - including the adaptations that >>>> the attackers made to the changes. This, to my mind, is the job of the >>>> working group: to look at the current status, discuss where the holes >>>> are and if they are protocol holes or if they are best practice / >>>> implementation holes. >>>> >>>> On a more practical point, we have a month to finalize the problem >>>> statement. No one has proposed language to include in the problem >>>> statement about what has worked and what hasn’t worked. Given the >>>> current state of the group, I simply don’t think we have the time to put >>>> this into the problem statement and get it out in time. >>>> >>>> I do think we have the time and space to discuss techniques after the >>>> problem statement is done and include it in one of the WG output >>>> documents.> >>> So far, unless I was napping when it happened, we don't have a working >>> group draft of the problem statement. >> We have two documents that are up for debate as the working group draft. >> Anyone else is welcome to provide an alternative for consideration as well >> - as Dave did and that is now being wrapped into Wei’s draft. >>> Personally, I'm waiting for draft-chuang-dkim-replay-problem-02 before >>> investing any more time on the problem statement. I think it would make >>> sense for the group to do a quick assessment of it, when it is available >>> and see if we want to adopt it as a working group draft (I strongly >>> suspect we do). >> That’s my feeling as well, particularly given no one else is stepping up to >> write a draft of the problem statement on behalf of the working group. If >> someone does have an alternative in progress please let me know. > > Do you plan adopt it as a working group draft? That's a critical step in the > process. Anything before that step needn't reflect anything other than the > author's opinion (and that's optional). In the absence of a competing draft and if that’s the consensus of the group, yes. Laura > > Scott K > > > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement
> On 27 Mar 2023, at 16:46, Scott Kitterman wrote: > > > > On March 27, 2023 3:10:40 PM UTC, Laura Atkins > wrote: >> >> >>> On 26 Mar 2023, at 11:13, Murray S. Kucherawy wrote: >>> >>> On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas >> <mailto:m...@mtcc.com>> wrote: >>>> On 3/24/23 6:19 PM, Barry Leiba wrote: >>>>> I don't agree with the premise. I think what was tried and didn't >>>>> work should be documented in the result that the working group comes >>>>> out with, but not in the problem statement. >>>> >>>> There isn't a place in the charter/milestones for that. >>> >>> The charter identifies these possible outputs in some combination: >>> >>> (1) a clear problem statement; >>> >>> (2) one or more protocol update document(s); >>> >>> (3) a statement of some kind that the WG determined no feasible protocol >>> solution exists (and, one would hope, how it reached this conclusion); >>> >>> (4) an update to current DKIM operational advice with respect to the stated >>> problem. >>> >>> The only constraint in the charter is that (2) and (3) are mutually >>> exclusive. >> >> Agreed with all of this. >> >>> I believe that a history of what techniques were previously tried and >>> failed could arguably go into any of them. The charter is neither >>> prescriptive or proscriptive on this point. >> >> >> It seems to me a history of what did work / didn’t will go into document 4 >> or the reasoning for document 3. My current preference is for the discussion >> to not be in the problem statement. My reasoning is that there will be >> discussion about what didn’t work and why it didn’t work. I expect that >> there will be quite a bit of back and forth to capture the details of why >> something didn’t work - including the adaptations that the attackers made to >> the changes. This, to my mind, is the job of the working group: to look at >> the current status, discuss where the holes are and if they are protocol >> holes or if they are best practice / implementation holes. >> >> On a more practical point, we have a month to finalize the problem >> statement. No one has proposed language to include in the problem statement >> about what has worked and what hasn’t worked. Given the current state of the >> group, I simply don’t think we have the time to put this into the problem >> statement and get it out in time. >> >> I do think we have the time and space to discuss techniques after the >> problem statement is done and include it in one of the WG output documents. >> > So far, unless I was napping when it happened, we don't have a working group > draft of the problem statement. We have two documents that are up for debate as the working group draft. Anyone else is welcome to provide an alternative for consideration as well - as Dave did and that is now being wrapped into Wei’s draft. > Personally, I'm waiting for draft-chuang-dkim-replay-problem-02 before > investing any more time on the problem statement. I think it would make > sense for the group to do a quick assessment of it, when it is available and > see if we want to adopt it as a working group draft (I strongly suspect we > do). That’s my feeling as well, particularly given no one else is stepping up to write a draft of the problem statement on behalf of the working group. If someone does have an alternative in progress please let me know. > Once that's done, I think there will be a solid basis for progress towards > the milestone. > > In the meantime, if someone wants to write up a section on what's been tried, > I don't think it's on the critical path for the milestone until there's > agreement to add it to the document. It certainly doesn't delay anything now > while we're waiting for the -02 of the problem statement. If the text can be > developed in parallel, it might not affect the schedule significantly. > Myself, if we can, I think we should (I will volunteer to review and provide > feedback on this but not to write it - I don't have the time). That makes sense and I support doing the work in parallel. Do we have volunteers to write up some of what’s been tried? laura -- 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] What has been tried and doesn't work should be documented in the problem statement
> On 26 Mar 2023, at 11:13, Murray S. Kucherawy wrote: > > On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas <mailto:m...@mtcc.com>> wrote: >> On 3/24/23 6:19 PM, Barry Leiba wrote: >> > I don't agree with the premise. I think what was tried and didn't >> > work should be documented in the result that the working group comes >> > out with, but not in the problem statement. >> >> There isn't a place in the charter/milestones for that. > > The charter identifies these possible outputs in some combination: > > (1) a clear problem statement; > > (2) one or more protocol update document(s); > > (3) a statement of some kind that the WG determined no feasible protocol > solution exists (and, one would hope, how it reached this conclusion); > > (4) an update to current DKIM operational advice with respect to the stated > problem. > > The only constraint in the charter is that (2) and (3) are mutually exclusive. Agreed with all of this. > I believe that a history of what techniques were previously tried and failed > could arguably go into any of them. The charter is neither prescriptive or > proscriptive on this point. It seems to me a history of what did work / didn’t will go into document 4 or the reasoning for document 3. My current preference is for the discussion to not be in the problem statement. My reasoning is that there will be discussion about what didn’t work and why it didn’t work. I expect that there will be quite a bit of back and forth to capture the details of why something didn’t work - including the adaptations that the attackers made to the changes. This, to my mind, is the job of the working group: to look at the current status, discuss where the holes are and if they are protocol holes or if they are best practice / implementation holes. On a more practical point, we have a month to finalize the problem statement. No one has proposed language to include in the problem statement about what has worked and what hasn’t worked. Given the current state of the group, I simply don’t think we have the time to put this into the problem statement and get it out in time. I do think we have the time and space to discuss techniques after the problem statement is done and include it in one of the WG output documents. laura (as chair) -- 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] What has been tried and doesn't work should be documented in the problem statement
+1 > On 25 Mar 2023, at 01:19, Barry Leiba wrote: > > I don't agree with the premise. I think what was tried and didn't > work should be documented in the result that the working group comes > out with, but not in the problem statement. > > Barry > > On Sat, Mar 25, 2023 at 8:57 AM Michael Thomas wrote: >> >> >> And yes, that means spam filters and the rest of the ecosystem around >> email in which DKIM operates. As in, why exactly are we here? Why can't >> industry groups come up with their own solutions? We either document it >> now, or argue about it later especially when it becomes plain that there >> is no protocol solution and that a BCP is the only possible positive >> outcome of this rechartering. An outcome that is specifically allowed >> for in the charter I will note. It need not be exhaustive, but it would >> be good to document some of the constraints on the solution space as >> well as what has been tried and failed. x= is a perfect example. >> >> Also: there has not been any consensus that the shape and scope of the >> two current proposals is correct or sufficient. We are far from the >> point that this is just wordsmithing imo, appeals to the contrary not >> withstanding. >> >> Somebody brought up that this could turn into a research project. >> Frankly I think that is highly likely the case and is why rechartering >> was so problematic. Since M3AAWG can't figure it out with lots of inside >> the industry information, what makes anybody think the wider community >> would have better insight which is not speculative because it has been >> tested and known to work? It speaks volumes that they didn't have a >> solution in mind and bring it to IETF to vet in the wider community. >> That sure sounds like a research project to me. >> >> Mike >> >> ___ >> Ietf-dkim mailing list >> Ietf-dkim@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-dkim > > ___ > 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] Comments on draft-chuang-dkim-replay-problem
figure out > what cache duration is appropriate to catch replays while not also catching > legitimate mail. > > The "sign for the next hop" proposal could use a language tweak of some kind. > I can't quite put my finger on it. If it's "sign for the next hop" at a > host level, I have to know that host; today, I just sign and toss it in the > queue, and my MTA figures out which MX is going to take it, but if I have to > know which MX that is, I can't sign until connection time; milter-based > filters at least don't work that way because the integration point doesn't > allow it. If it's actually "sign for the next ADMD", that problem goes away, > but the definition of "ADMD" gets a bit muddy because now you have to include > in that definition any MX that might be providing transparent > store-and-forward. Need to think a little more about this. > Section 5 you won't need. > > Section 6 can simply say there are no security considerations for a problem > statement document, though you anticipate some interesting ones in documents > to follow. :-) > > Lastly, you can drop the "yet" from Section 7. :-) Thanks. laura > > -MSK > ___ > 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] What has been tried and doesn't work should be documented in the problem statement
I asked yesterday for commentary on the drafts as an attempt to move the discussion forward so we could discuss the shape and scope of the current proposals. I would politely request that you confine discussions of the shape and scope to that thread, rather than staring yet a different thread. laura > On 24 Mar 2023, at 23:57, Michael Thomas wrote: > > > And yes, that means spam filters and the rest of the ecosystem around email > in which DKIM operates. As in, why exactly are we here? Why can't industry > groups come up with their own solutions? We either document it now, or argue > about it later especially when it becomes plain that there is no protocol > solution and that a BCP is the only possible positive outcome of this > rechartering. An outcome that is specifically allowed for in the charter I > will note. It need not be exhaustive, but it would be good to document some > of the constraints on the solution space as well as what has been tried and > failed. x= is a perfect example. > > Also: there has not been any consensus that the shape and scope of the two > current proposals is correct or sufficient. We are far from the point that > this is just wordsmithing imo, appeals to the contrary not withstanding. > > Somebody brought up that this could turn into a research project. Frankly I > think that is highly likely the case and is why rechartering was so > problematic. Since M3AAWG can't figure it out with lots of inside the > industry information, what makes anybody think the wider community would have > better insight which is not speculative because it has been tested and known > to work? It speaks volumes that they didn't have a solution in mind and bring > it to IETF to vet in the wider community. That sure sounds like a research > project to me. > > Mike > > ___ > 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] Comments on draft-chuang-dkim-replay-problem
> On 24 Mar 2023, at 18:14, Scott Kitterman wrote: > > > > On March 24, 2023 5:42:41 PM UTC, Michael Thomas wrote: >> >> On 3/24/23 10:22 AM, Murray S. Kucherawy wrote: >>> >>> >>> Fine with me, it's far from a showstopper overall. I just made the >>> suggestion. >>> >> This wg should be concerned with DKIM problems, not other wg problems and >> especially for experimental rfc's of dubious value and complete mysteries as >> to what they have to do with their actual charter. > > As long as you include integration of DKIM into the overall email > architecture and broader impacts of DKIM changes as part of 'concerned with > DKIM problems', I agree. I agree with this. We do, I think, need to acknowledge that DKIM is part of a complicated landscape of authentication protocols that are independent and interdependent. laura (participating) -- 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] Clarifying the problem
> On 24 Mar 2023, at 16:48, Michael Thomas wrote: > > > On 3/24/23 6:14 AM, Laura Atkins wrote: >> Please, let’s focus on the current issue with is addressing and refining >> the problem statement. > > So you agree with me that any discussion of ARC and its complete failings > should be out of scope? I would appreciate the chairs enforcing that. I said we should be focusing on addressing and refining the problem statement. laura -- 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] Problem statement adoption
Great! Thanks. laura > On 24 Mar 2023, at 14:14, Wei Chuang wrote: > > +1 I'm working on it. > > -wei > > On Fri, Mar 24, 2023, 6:45 AM Dave Crocker <mailto:d...@dcrocker.net>> wrote: >> On 3/24/2023 6:42 AM, Laura Atkins wrote: >> > We currently have two problem statements to discuss for adoption. >> >> Wei is merging 'mine' into his. (Note mine was done as a variant of his.) >> >> I believe there will again be only one draft. >> >> d/ >> >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net <http://bbiw.net/> >> mast:@dcrocker@mastodon.social >> >> ___ >> Ietf-dkim mailing list >> Ietf-dkim@ietf.org <mailto: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
[Ietf-dkim] Problem statement adoption
We currently have two problem statements to discuss for adoption. In order to move the adoption forward can we get some specific consensus on the drafts that we currently have on the table or some specific wording changes needed before adoption. The drafts on the table: Draft 1: https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/ Draft 2: https://datatracker.ietf.org/doc/draft-crocker-dkim-replay/ Questions to answer: Should we adopt Draft 1? Should we adopt Draft 2? Alternatively: Should we take Draft 1 or Draft 2 and edit or modify it to reflect the consensus of the group? Do we have any volunteers to handle editing duties? laura -- 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] Process Questions
>>> >>>> On 10 Mar 2023, at 00:30, Michael Thomas >>>> <mailto:m...@mtcc.com> wrote: >>>> >>>> Now that we have a chair, I have a question about process wrt to the >>>> charter. The charter states that either the working group will produce >>>> documents addressing the problem, or it will produce a document saying why >>>> it can't do anything about it within the IETF confines. I strongly suspect >>>> that that the latter will be the conclusion but I don't know what the >>>> process would look like to come to that conclusion. It seems like it >>>> entails a long list of "can't do this"'s etc followed by "we give up". But >>>> that list could be nearly endless if it is allowed to get out of hand. So >>>> what does it take to come to that conclusion from a process standpoint? >>> >>> Our current milestones are: >>> >>> Apr 2023 - Post a consensus problem statement draft to the datatracker (may >>> not go to the IESG) >>> >>> Jun 2023 - Proposal regarding plans for remaining document(s) presented to >>> the AD >>> >>> Dec 2023 - Submit technical specifications for replay-resistant DKIM >>> enhancement(s) to the IESG at Proposed Standard >> >> Per the charter, Or Not. That is what I'm asking about. >> > > Between the milestones and the charter text, the charter text is typically > the more important of the two. Milestones can be edited without full IESG > review, while the charter can't. So if the working group needs more time > than April or June, that can be negotiated. I’d like to get a problem statement done by April. What I’m seeing is a lot of people focused on solutions or having side discussions about spam filters rather than looking at the wording of the two proposed problem statements we have on the table. > Plus, frankly, I made up those dates during chartering. The chairs and I > haven't discussed whether they're reasonable or whether something else should > be there. If people want to propose adjustments, I'm all ears. I do want to stick with April for the problem statement. It should be a deadline we can meet with a little bit of focus on defining the problem statement. laura > > -MSK, this time with the AD hat on > ___ > 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] Clarifying the problem
Please, let’s focus on the current issue with is addressing and refining the problem statement. laura > On 23 Mar 2023, at 20:27, Michael Thomas wrote: > > > On 3/23/23 2:52 AM, Alessandro Vesely wrote: >> On Wed 22/Mar/2023 20:31:51 +0100 Michael Thomas wrote: >>> On 3/21/23 8:01 PM, Murray S. Kucherawy wrote: >>> >>>>> 1. What percent of incoming email to a mailbox is through >>>>> resenders and of that what percent resign? >>>> >>>> By "resign" you mean something that has signatures from two domains, >>>> correct? If so, how could one tell whether the originating operator did >>>> or did not attach one or more of them? >>> >>> As in a mailing list makes a breaking change but resigns it with its own >>> domain. The mailing could obviously sign their auth-res which if they have >>> a good reputation the receiver might trust as a reasonable proxy. >> >> >> That's reinventing ARC! > > No, ARC is reinventing DKIM. Needlessly. > > >> >> I too used to be very skeptic about ARC (mainly because of the conjectured >> assumption that ARC sealers can be trusted based on an available reputation >> database, which skews usability toward global providers). I changed my mind. >> >> As a special flavor of DKIM designed around forwarding, ARC can bring real >> means to solving this problem. Indeed, signing or sealing the messages to >> be forwarded can uncover the intent and the maker of the forwarding. >> > I have yet to see anything that convinces me that ARC brings anything new and > useful to the table. After much hand waving when I was trying to figure out > what ARC was about, John Levine finally said that it all boils down to > reputation. Well, guess what. The same goes from DKIM for both originators > and intermediaries. There has always been the ability to build reputation > regardless of the domain doing the signing. This re-chartering of the DKIM wg > wouldn't be happening if that were not true. There seems to be an awful lot > of magical thinking going on with it. > > Mike > > ___ > 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] Process Questions
> On 10 Mar 2023, at 00:30, Michael Thomas wrote: > > Now that we have a chair, I have a question about process wrt to the charter. > The charter states that either the working group will produce documents > addressing the problem, or it will produce a document saying why it can't do > anything about it within the IETF confines. I strongly suspect that that the > latter will be the conclusion but I don't know what the process would look > like to come to that conclusion. It seems like it entails a long list of > "can't do this"'s etc followed by "we give up". But that list could be nearly > endless if it is allowed to get out of hand. So what does it take to come to > that conclusion from a process standpoint? Our current milestones are: Apr 2023 - Post a consensus problem statement draft to the datatracker (may not go to the IESG) Jun 2023 - Proposal regarding plans for remaining document(s) presented to the AD Dec 2023 - Submit technical specifications for replay-resistant DKIM enhancement(s) to the IESG at Proposed Standard Dec 2023 - Submit revised operational advice for replay-resistant DKIM use to the IESG at Informational Coming to the conclusion will be done in the same manner as IETF decisions are made: by group consensus. That includes the consensus on whether or not this is a protocol problem or an operational problem. As I read the charter, that decision needs to be made by June, meaning we have slightly more than 2 1/2 months to reach it. That gives us a specific time constraint for that discussion. > Also: if M3AAWG is producing its own BCP can that actually be taken as an > IETF BCP? > Wouldn't it need to just be informational since the IETF community had no > input to its making and the deliberation behind it? Since I'm not a member, > it's opaque to me about the reasoning and what guided the recommendations. > Worse is that since there is so much opaque industry secrecy surrounding > this, it's pretty much impossible to test the recommendations to see if they > are correct. The IETF process will be followed for any documents published by this working group. laura -- 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] Welcome to the rechartered working group
> On 9 Mar 2023, at 22:47, Michael Thomas wrote: > > > On 3/7/23 4:09 AM, Laura Atkins wrote: >> There is a current problem statement at >> https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/. Please >> take a moment to read through it and provide feedback. This chair thinks we >> should not be providing solutions in the problem statement. We should be >> primarily describing what the issue is and why we think the issue is with >> the protocol. We will deal with solutions in the actual document. > > What about solutions that have been tried but have drawbacks or are > ineffective? It would be nice to know what the current baseline is. In some respects that depends on what form the final document takes. If we do decide that the underlying problem is something that can be addressed with a protocol change, then we probably won’t mention mitigation steps that have been tried and either have drawbacks or are ineffective. If the outcome is a document that we looked at the problem and decided that the issue isn’t with the protocol and we recommend no protocol changes then I can see the work product being a discussion of non-protocol solution space. That would include different things folks have tried what works and what doesn’t work. > Also: I continue to be concerned about the hand wave-iness of the problem. > That is both from the standpoint of M3AAWG which is members only and more > importantly from various vendors who for their own reasons have little or no > desire to disclose pertinent pieces of information in public. It's rather > hard to "fix" a black box when you don't even know what it's doing. You made your concerns abundantly clear during the re-chartering discussion. Given the IETF chose to recharter, the next steps are to craft a problem statement that documents and explains a DKIM replay attack in a way that’s accessible and understandable. Do you have any questions, edits or specific wording related to better explaining the problem for either of the drafts that are currently under discussion? laura -- 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
[Ietf-dkim] Welcome to the rechartered working group
All The DKIM working group is now active again (thanks Murray!). The chairs wanted to send out a short note to welcome everyone and talk about our next steps. Our first deadline is next month - to get a consensus problem statement submitted on the IETF data tracker at https://datatracker.ietf.org/group/dkim/ There is a current problem statement at https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/. Please take a moment to read through it and provide feedback. This chair thinks we should not be providing solutions in the problem statement. We should be primarily describing what the issue is and why we think the issue is with the protocol. We will deal with solutions in the actual document. There was also a DKIM replay session at the most recent M3AAWG meeting. As I understand it, they’re working on a BCP in parallel with the IETF. Many folks are active in both groups. Due to M3AAWG privacy requirements, we are constrained in what we can share from the meeting itself. However, if you were here and were on the panel or part of the discussions, feel free to share with us some of your thoughts on the problem, possible solutions and what your organizations have done to address the issue. One of the panel members has shared the following from what he said at the session: * RFC 6376 itself says "x=" is not a viable mechanism to deal with replay. * There may only be a best practices solution, and not a protocol solution. * DKIM has since the beginning kept itself completely separate from the message transport. Several of the proposed solutions (including mine) take leaps of varying sizes into the realm of DKIM knowing something about the transport; the lightweight ones connect the message to the envelope somehow, and the more heavyweight ones mean DKIM filters have to learn about MXes and whatnot. We have to be absolutely certain that we want to break that wall if we go this way, because once we do, there will be no turning back. There was also a DKIM replay session at the most recent M3AAWG meeting. As I understand it, they’re working on a BCP in parallel with the IETF. Many folks are active in both groups. Due to M3AAWG privacy requirements, we are constrained in what we can share from the meeting itself. However, if you were here and were on the panel or part of the discussions, feel free to share with us some of your thoughts on the problem, possible solutions and what your organizations have done to address the issue. We will not meet in Yokohama due to the timing of being rechartered, but we are considering a one hour interim in April if there appears to be points of discussion. laura (as chair) -- 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] DKIM Replay Problem Statement and Scenarios -01 draft posted
> On 16 Feb 2023, at 04:16, Murray S. Kucherawy wrote: >> >> There are *tons* of external dependencies on the filtering MTA. I really >> can't imagine that this would be the straw that breaks the camel's >> back. > > Depends (as I think Scott said) on the size and resources available to the > operator, and how much they're a target of this attack. We've generally > shied away in the past from solutions of the form "you have to be at least > this tall to play". The flip side of that is that spammers are not equal opportunity: they target the large consumer mailbox providers. So if the problem only affects groups that are this tall, then a solution that fixes it for those providers might be reasonable. laura -- 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] Setting a stage for detection
> On 12 Feb 2023, at 20:48, Wei Chuang > wrote: > > > > On Sun, Feb 12, 2023 at 12:16 PM Dave Crocker <mailto:d...@dcrocker.net>> wrote: > Folks, > > There appears to be no perfect way to distinguish a Replay attack from a > legitimate re-posting by an Alias or even a Mailing list (that preserves > the original DKIM signature.) > > The only 'signal' that is valid, also is ambiguous. The signal is that > the rfc5321.Mail command has an address that is not in any of the > rfc5322 address fields. The ambiguity, of course, is that that's also > true for Alias. > > I'm wondering about designing some assistance by the author's platform > and the Aliasing platform, to flag what they've done. > > Imagine adding a header field like "Separate-Envelope:", possibly > listing the domain name of the site putting the flag there, and having > them add a DKIM signature to cover it and the rest of the message. > > This could also be done by a spammer doing Replay, of course. But the > point is that this added mechanism now creates a noise-free basis for > evaluating this class of traffic associated with that signed domain. > > Agreed that reputation systems can play a role when the spammer decides to > participate. One thing I’ve been telling folks is that a DKIM d= isn’t a reputation. The d= is a strong identity. That identity can be used to hang a reputation on - where the reputation is based on all the mail containing that identity. I think it might be helpful if we shifted the discussion from DKIM is a reputation to DKIM is an identity. That reframes the question as: How do we improve the DKIM protocol so that we can minimize the ability of an unauthorized 3rd party to misappropriate the identity of the signer? laura > > It's not that the receiving filter could not detect the disparity > between envelope and content addresses. It's that the receiver is > getting a flag from whomever did it. > > If, for example, the domain name is of the originating service, then > it's clearly not Replay. > > If it is from an Aliasing site, the receiver can quickly build up a > reputation for that site, to aid in determining replay or not. > > Thoughts? > > In this model, let's consider the Receiver's actions. > 1. Say the spammer doesn't want to participate in creating a > Separate-Envelope, how would a receiver detect this as Replay? Is the idea > that Separate-Envelope identifies the Alias or Mailing-lIst? Is the > verification process that the Receiver notices that the header is missing? > 2. You've noted what happens when the spammer participates in generating > Separate-Envelope > 3. A non-spammer should have a Separate-Envelope, which will validate. > > FWIW a different approach but overlaps this idea is that a sender identifies > the domain they intend to send to. The receiving system verifies that they > are the intended recipient domain. I think John Levine has a draft about > this. I have a draft that expands some of that idea further. > > -Wei > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net <http://bbiw.net/> > mast:@dcrocker@mastodon.social > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org <mailto:Ietf-dkim@ietf.org> > https://www.ietf.org/mailman/listinfo/ietf-dkim > <https://www.ietf.org/mailman/listinfo/ietf-dkim> > ___ > 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] DKIM Replay Problem Statement and Scenarios -01 draft posted
> On 12 Feb 2023, at 21:49, Michael Thomas wrote: > > > > On 2/12/23 1:34 PM, Murray S. Kucherawy wrote: >> On Fri, Feb 10, 2023 at 2:13 PM Michael Thomas > <mailto:m...@mtcc.com>> wrote: >> Another thing that should probably be discussed is outbound spam filtering. >> At a high level, this is really about the sender sending spam. But email >> afaik is silent on whether senders or receivers should filter for spam (and >> if there is, it would be good to reference it). Sender filtering is >> especially pertinent and may well have clues of how a sender can mitigate >> it. A breakdown of how spammers defeat that outbound filtering would be >> really useful. For example, is the spam intended for mailboxes on the >> sending domain (eg, gmail)? Or do they go through a two stage process where >> they first get the spam through the sender, and then test it on the intended >> receiving domains? All of that would be really helpful. >> >> I think it's sufficient for us to acknowledge that, in either direction, no >> spam filter is 100% accurate. It can be tempting to say "You shouldn't sign >> spam, and if you do, you're the problem", but I'm sympathetic to those in >> that business who are faced with the reality that they'll never get it 100% >> right. Instead, I think we have to accept that reputable signers will >> occasionally be tricked into signing spam, and the goal then is to try to >> develop some new signal that can be provided to verifiers to handle those >> cases. >> >> The problem statement document proposed for the WG does spell this out, I >> think. What do you find missing in terms of the details? Some of the nitty >> gritty probably varies from one email provider to the next, for example. >> > It didn't exactly call it out? It called out outsourced outbound filtering I > thought, but that's just acknowledging that it exists? Or did I miss > something? > > Maybe what's needed is essentially what you wrote. > > "while senders intent on keeping a good reputation must filter outbound mail > for spam and other abuse, these filters are not 100% effective." > > Basically saying if you're not filtering outbound mail for abuse, you're part > of the problem. > I don’t see how that’s relevant to the discussion here. Most of the outbound mail is not detectable as spam (it’s not sent in bulk and it is sent to opt-in email addresses). So it won’t catch the send-one-message-to-myself case. If we’re looking at linking to spam landing sites, it’s trivial for the site to show one thing during the initial send and then be a wholly different site when it’s sent by the spammer. The issue at hand is: can we tighten up the DKIM protocol to make it more resistant to replay attacks? Telling the victims that the problem is they’re not doing outbound filtering isn’t helpful, nor does it address the problem. Expecting the spammer to do outbound filtering doesn’t seem to be a useful pathway. If we could convince spammers to outbound filter their spam we’d have solved the problem. laura -- 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] Misuse of antiforgery protocols
> On 15 Dec 2022, at 00:46, Grant Taylor > wrote: > > On 12/14/22 11:10 AM, Evan Burke wrote: >> It doesn't. Most of the accounts are caught before sending. All it takes is >> one to slip through the anti-spam detections and then go send millions of >> replay spam messages or more - even if that account is shut down quickly >> after sending. > > What would happen if the ESPs DKIM implementation got, possibly a LOT, more > complex in that key pairs used to sign outgoing email from clients with keys > specific to each client? > > That way if ~> when the ESP needed to cancel a client's service, the ESP > could also withdraw the client's public key in the ESP's zone(s) thereby > breaking the DKIM signature by rendering it unvalidatable. I'd think that > this would largely comedown to a TTL issue on the DKIM's public key record in > DNS and implementation complexity. > > What am I failing to take into account? Operational overhead. laura -- 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] Misuse of antiforgery protocols
> On 12 Dec 2022, at 14:34, Murray S. Kucherawy wrote: > > On Mon, Dec 12, 2022 at 1:13 AM Alessandro Vesely <mailto:ves...@tana.it>> wrote: > > The alternative is to say: Well, if you can't make at least one of those > > two quantities bulletproof, then don't sign your mail. That, though, > > sounds a lot to me like tossing DKIM in the bin. > > On the opposite, if Gmail restricted signing to accountable users only, its > signatures would gain value. If they started doing so it would soon be > noticed, and signatures would acquire a meaning in delivery decisions. > > Is the cost of imposing a program that vets every user comparable to that of > the damage caused by this attack vector? My impression is that it is not. I’m not aware of Gmail being a significant victim here - although it’s possible they are. > Endowing signatures with a significant value increases the overall value of > DKIM. > > Presumably they already have significant value. That's why this attack works > already. They’re an identity of a known sender that invests time and resources into building and managing their reputation. Google? Maybe not. But the email service providers who do a lot to keep the spammers off their network are a common victim. These spammers know that they get better delivery if their mail is signed by the email service provider. The email service provider’s detectors and defenses are enough to stop the spammer from being able to send through the ESP. So the spammer sends one email to an account they own and takes a reputation they’ve already been told they shouldn’t be using. A DKIM signature is an identity. That identity has a reputation. Attacks that borrow the identity belonging to senders with good reputation benefit from that reputation. It’s not about any DKIM signature. It’s not about a random DKIM signature. It’s about a known entity. Even if Gmail only signed mail from accountable users, there is still the possibility of spammers posing as accountable users. The whole idea of a DKIM replay attack is that this is mail that cannot be directly sent through the infrastructure of the domain owner. That, itself, implies the domain owners are doing quite a bit to stop the spam from coming out of their network. If they weren’t doing a good job then replay attacks wouldn’t be happening - the mail would just be sent over that network directly. Asking for the domain owners to “stop sending spam” when the whole replay process indicates they are stopping spam out of the networks they control seems a bit of a non-starter to me. > The question is whether we should proclaim that the bar needs to be even > higher, maybe even an all-or-nothing proposition. I'm suggesting that's not > a good idea. Agreed. laura -- 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] Misuse of antiforgery protocols
> On 11 Dec 2022, at 21:41, Michael Thomas wrote: > > > > On 12/11/22 1:16 PM, Murray S. Kucherawy wrote: >> On Sun, Dec 11, 2022 at 1:11 PM Michael Thomas > <mailto:m...@mtcc.com>> wrote: >> >>> As for resolution: the first obvious one is to not send spam in the first >>> place. That is the root of the problem. The second is that Bcc's can be >>> treated with more suspicion. Neither of these needs the working group to do >>> anything. >>> >>> >>> I think this is easier said than done. In the example I gave, "don't send >>> spam in the first place" reduces to "make sure your users are 100% >>> trustworthy or that your outbound spam filters are 100% accurate", which >>> strikes me as an impossible bar to meet. >> I'm going to assume that the attackers will need to iterate to find a piece >> of mail that passes their filters. That is signal right there that abuse is >> likely. Perhaps an exponential backoff could be employed when outbound spam >> is detected. Sort of like a 4xx "try later". >> >> That's easy to evade: Come from a rotating pool of IP addresses, using a new >> free account each time. > Sure. I guess the question is how much effort would spammers be willing to > expend before trying some other tactics? Quite a bit, actually. I remember sitting in a 17th floor conference room on market street with a particular sending organization that explained to me their business model was to have a boiler room full of people iterating through content and trying to deliver it to their own mailbox at hotmail.com <http://hotmail.com/>. When they found text that got through, they sent that until the filters caught up, then moved onto the next piece of content. They started this at 5pm pacific time and would spam all night. They did this every day. That was 2007 or so (said company was sued into oblivion by the FTC not long after that conference room meeting). The amount of energy spammers expend to bypass filters is significant. That includes bypassing port25 blocks. For instance, I’m aware of a company using BGP routing tricks to host their outbound spam cannons on major cloud providers (that block port25 by default). The IPs are treated as throwaway and they burn and turn them when they get too blocked. > Can we even quantize what the value of, say, a signed gmail piece of email > is? I think that's a basic question that needs to be answered before we > declare this a problem. I for one am all ears as "DKIM gives you better > deliverability" has always been a sort of squishy statement. This is one of those questions that is, IMO, unanswerable for a lot of reasons. The biggest of which is: the value to whom? >> >> But the BCC aspect is interesting too. Don't providers already view things >> with massive rcpt-to (bcc's) suspiciously? hat's easy to evade: Send a spam >> message to yourself only. That has the signature. Now capture that from >> your inbox and replay it from a different server to any number of >> recipients, using any number of envelopes, to your heart's content. Won't >> pass SPF, but it passes DKIM. If the receiver values DKIM more, or only >> cares if one passes, you win >> > No, I mean that the if number of RCPT-TO's is large, it's suspicious. Even if > they do individual SMTP transactions it will have the same (signed) > Message-Id so that's not evadeable either in theory. > Interesting thought. laura -- 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] Misuse of antiforgery protocols
> On 11 Dec 2022, at 20:52, Murray S. Kucherawy wrote: > > On Sun, Dec 11, 2022 at 12:34 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: > Re: stripping signatures, all the attacker needs to do is either send it to a > service that doesn't strip signatures or use their own MTA. Trivially > avoidable, and a Maginot Line of epic narrowness. > > Right, I think this is an aspect of that proposal that warrants further > debate. I think the argument is compelling, but it's clearly not bulletproof. > > As for resolution: the first obvious one is to not send spam in the first > place. That is the root of the problem. The second is that Bcc's can be > treated with more suspicion. Neither of these needs the working group to do > anything. > > I think this is easier said than done. In the example I gave, "don't send > spam in the first place" reduces to "make sure your users are 100% > trustworthy or that your outbound spam filters are 100% accurate", which > strikes me as an impossible bar to meet. Also, in the case of replay attacks, we’re redefining spam to a point of uselessness. Spam is mail that users didn’t ask to receive. But the initial message that’s being signed is an opt-in message. The sender knows the recipient address wants the message. We’ve spent 25 years trying to block spam, I’m not sure that this is even a solveable problem. Even if you made COI the default and could only send mail with an actual confirmation message in hand, that’s a trivially jumpable hoop for the spammer to negotiate. > The alternative is to say: Well, if you can't make at least one of those two > quantities bulletproof, then don't sign your mail. That, though, sounds a > lot to me like tossing DKIM in the bin Agreed. laura -- 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 8 Dec 2022, at 00:26, Murray S. Kucherawy wrote: > > On Wed, Dec 7, 2022 at 2:06 PM Dave Crocker <mailto:dcroc...@bbiw.net>> wrote: > As appealing as the AS concept is, I've never been clear how operationally > useful they are. > More to the current point, if the anti-replay work to be done benefits from a > position on transit vs. non-transit, then including it directly in an > anti-replay specification would be more helpful than in a separate AS. > > Fair enough. Does the charter need to say that a revision to best practices, > relative to the replay problem, might be a possible output? It's within the > realm of possibility that no protocol work comes out of this, but a > "checkpoint" about current realities might be good to publish in that case. I think a checkpoint / review is a good goal for the group. laura -- 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] not removing signatures
> On 7 Dec 2022, at 17:16, Barry Leiba wrote: > >> The purpose of a DKIM signature is, as our original statement put it, to >> make sure that a message from your >> bank actually came from your bank, even if it passed through your alumni >> association. Once it arrives to your >> real mailbox, that signature is not needed. > > As long as the signature is not removed in the alumni case I'm > somewhat less concerned, but... > > In some systems, sieve scripts and other filtering is done *after* the > MUA drops the message in the delivery mailbox. If that drop removes > the signature, that hampers the sieve/filtering process severely. A > sieve "redirect" becomes impossible, and the filtering would not be > able to use the DKIM signature for other purposes either (though it > might be able to rely on the auth-results header field for some > things. > > That's what concerns me. Maybe there’s a split the baby piece where part of the signature is stripped. I’ll be honest, the only bits I really look at are s= and d=. Maybe stripping part (bh?) while leaving the useful bits is a solution. Of course, that is not going to address the replay attack problem at all. laura -- 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 3 Dec 2022, at 06:38, Murray S. Kucherawy wrote: > > I've placed what I believe is the text that is closest to consensus in the > datatracker: > > https://datatracker.ietf.org/doc/charter-ietf-dkim/ > <https://datatracker.ietf.org/doc/charter-ietf-dkim/> > > Please provide comments or criticism soon. Once it appears to be stable > relative to this audience, I'll send it on its way for internal (IESG) and > then full IETF review. > > Should you wish to serve as a co-chair, or nominate someone for that > position, please contact me off-list. +1 laura -- 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
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 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] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)
What’s stopping large providers from removing DKIM now if they wanted to? Or have they actually made the choice to keep the signatures in? If they have made that choice, do we know why? If they haven’t made the choice, how complicated will it be to change the inbound MTA to strip headers? Will this have knockon effects for their internal systems? Is there a risk that stripping the DKIM header will cause authentication failures if the messages are forwarded internally or externally? (I’m reminded of the time Microsoft changed some internal systems around and ended up having everything fail SPF because they were picking the wrong IP out of their mess of headers to do SPF authentication with). And, I think most importantly: will this recommendation by the IETF have any impact whatsoever on the groups currently using DKIM replay as a way to get past (some) filters? I don’t see how it will, most of them are using their own email addresses / servers to collect the replayed messages and then sending the messages out through their own systems. Even if Google and Microsoft and Yahoo and the other top 20 mailbox providers start stripping DKIM headers, the attackers will be able to find some service somewhere that doesn’t. Worst comes to worst, they stand up a MX on an EC2 instance and run their own code to collect the mail. laura > On 22 Nov 2022, at 18:56, mikespec...@gmail.com wrote: > > I have nothing much useful to add, except to say that I’m pro removing the > DKIM header for other privacy reasons. I also think the ietf signaling > support for this would be helpful in getting large email providers to push > forward with solutions here. > > KeyForge: Non-Attributable Email from Forward-Forgeable Signatures > usenix.org > > > <https://www.usenix.org/conference/usenixsecurity21/presentation/specter-keyforge>KeyForge: > Non-Attributable Email from Forward-Forgeable Signatures > <https://www.usenix.org/conference/usenixsecurity21/presentation/specter-keyforge> > usenix.org > <https://www.usenix.org/conference/usenixsecurity21/presentation/specter-keyforge> > > <https://www.usenix.org/conference/usenixsecurity21/presentation/specter-keyforge> > > ==Mike > >> On Nov 22, 2022, at 10:47 AM, Dave Crocker wrote: >> >> On 11/22/2022 6:12 AM, Scott Kitterman wrote: >>> On Tuesday, November 22, 2022 8:48:48 AM EST Alessandro Vesely wrote: >>>> On Tue 22/Nov/2022 01:21:00 +0100 Murray S. Kucherawy wrote: >>>>> We actually seemed to like the idea, at least back then, that the >>>>> signature >>>>> survives delivery so that it can be validated at any point later. >>>> Indeed, there are products, like Lieser's DKIM verifier plugin for >>>> Thunderbird[*], which verify DKIM on the MUA. >>> My desktop MUA of choice (kmail) includes the capability too. >> >> >> To the extent there is serious pressure to aid MUA awareness of the DKIM >> header-field for a received message, we can specify renaming the field (and >> removing the actual signature value.) >> >> This retains the desired signalling information, without being useful for >> replay. >> >> 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 > ___ > 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] DKIM reply mitigations: re-opening the DKIM working group
> On 15 Nov 2022, at 12:29, Murray S. Kucherawy wrote: > > On Mon, Nov 14, 2022 at 11:04 AM Laura Atkins <mailto:la...@wordtothewise.com>> wrote: > Does it make sense to add in a brief discussion of ‘responsibility for the > message'? As I see it, responsibility implies able to do something against > the originator of the message or act to stop the message if it turns out to > be a problem. If it’s your customer and the mail is going out over your > network you can disconnect them. If the mail isn’t going out through your > network, you have very little control and if you don’t have control can you > really be responsible. > > Personally, I'd be fine leaving this for the WG to debate rather than > settling it in the charter. I think both positions are defensible. +1 > RFC 6376 says "some responsibility"; it leaves open to discussion what that > really means. I'm sympathetic to the idea that Gmail (for example) filters > outgoing stuff looking for spam, but also that this has always been a > tactical arms race, and something you consider spam might not in that moment > agree with what their detection stuff can identify. Wei might argue that > their signature means "We attest that this passed through us, and we did our > best to make sure it was legitimate before it went out", than the more > absolute "We claim this is legitimate and we are willing to stake our > reputation on it" that some seem to infer. The latter might even be > incentive to consider not signing anymore. +1 laura -- 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] DKIM reply mitigations: re-opening the DKIM working group
> On 14 Nov 2022, at 09:41, Murray S. Kucherawy wrote: > > On Mon, Nov 14, 2022 at 12:42 AM Scott Kitterman <mailto:skl...@kitterman.com>> wrote: > > I don't think there's any point in pursuing solutions that require a human to > read/understand anything about header fields. > > Having reviewed the proposals again, it seems like anything that actively > makes replays harder without adding additional indirect mail flow failures > amounts to a plan to document the flow of the email to provide additional > signal for receivers to understand what's been replayed versus what's a > normal indirect flow. > > I'm inclined to think that instead of specifying specific drafts to consider, > the charter should point to the problem statement draft instead. > > The drafts don't all have to be developed by the working group. It's > traditional for the charter to offer some drafts as things to consider, as > starting points for discussion. The working group can then choose to adopt, > all, some, or none of them. > > I think it was Barry who mentioned that a problem statement could be in a > document that never gets published. I believe we could also include a > problem statement in the charter itself, if it can be brief enough and > doesn't need examples and so forth to make its point. Does it make sense to add in a brief discussion of ‘responsibility for the message'? As I see it, responsibility implies able to do something against the originator of the message or act to stop the message if it turns out to be a problem. If it’s your customer and the mail is going out over your network you can disconnect them. If the mail isn’t going out through your network, you have very little control and if you don’t have control can you really be responsible? laura -- 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] DKIM reply mitigations: re-opening the DKIM working group
> On 11 Nov 2022, at 13:06, Alessandro Vesely wrote: > >>> [*] Previous messages use ESP, which I tend to associate to operators like >>> Mailchimp, say, rather than Gmail. I had a hard time trying to understand >>> why ESPs would let folks send a single opt-in message... Is it me? >> Why wouldn’t they? I sent myself a test message to make sure it was right >> before triggering the send to a larger list (and, BTW, Mailchimp actually >> limits the number of tests you can do). It’s basic QA. > > > Were you really talking about ESPs? Yes. I was. laura -- 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] DKIM reply mitigations: re-opening the DKIM working group
> On 11 Nov 2022, at 11:33, Alessandro Vesely wrote: > > On Fri 11/Nov/2022 10:23:44 +0100 Laura Atkins wrote: >>> On 11 Nov 2022, at 05:04, Scott Kitterman wrote: >>> [...] >>> >>> For those that have been around for awhile this reminds me of the now long >>> dead controversy about closing open relays. It's not identical, but I >>> think it rhymes. >>> Back in the mists of the early Internet we didn't have submission services >>> because any client could send email via (most) any MTA, so they weren't >>> needed. As you can imagine, spamming was incredibly easy and the community >>> gradually came around to the point that you can't just relay email for >>> anyone, an MTA should serve authorized users (I oversimplify here). As >>> this consensus was being developed, a substantial number of MTA operators >>> objected. Eventually, being an open relay meant no one would take mail >>> from you. >>> This seems similar. >> I was around for the open relay discussions and I don’t see the parallels. > > > I do. > > Going to a mailbox provider (MP[*]), obtain an email address, and send a > message from it is paralleled to going to an open relay and send a message > through it. The only differences are (1) the From: domain is constrained by > the MP, and (2) the MP requires me to interact with their web server in order > to setup an address. They both seem negligible to me. > > The MP limits the volume of messages that a user can send out. However, by > signing even one message, it takes the responsibility for its content. This appears to be the disconnect. The MP takes responsibility for the *MESSAGE* - that message, sent to that user. > After all, DKIM was designed to allow discernment based on domain name rather > than IP address. No surprise that someone can abuse a domain name through > different IP addresses. A hasty and imprudent signature could easily cause > risks. > > Now, why does the MP take responsibility for unknown content? They don’t. They take responsibility for the message. > If we extend the open relays parallel, we'd forecast that allowing anonymous > users to freely setup (hundreds of) email addresses has to come to an end. > Do MPs know the people they provide email services to? If they do, they can > afford the risk to put their reputation in their hands. > > IOW, the simple solution is that free MPs send messages unsigned except for > people they trust. Just so I’m clear what you’re suggesting, what I’m hearing you say is that from Google, Yahoo, and Microsoft should be sent without a DKIM signature in the absence of some proof of identity for the sender? > [*] Previous messages use ESP, which I tend to associate to operators like > Mailchimp, say, rather than Gmail. I had a hard time trying to understand > why ESPs would let folks send a single opt-in message... Is it me? Why wouldn’t they? I sent myself a test message to make sure it was right before triggering the send to a larger list (and, BTW, Mailchimp actually limits the number of tests you can do). It’s basic QA. laura -- 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] DKIM reply mitigations: re-opening the DKIM working group
sses with statistically significantly worse > reputation than the reputation of the domain and treat those messages more > suspiciously. I don't know that I would spend effort on special signature > decoding mechanisms that are inherently risky for false positives. But are you representative? > Although not in scope for this discussion, SPF can have similar issues when > ESPs are not sufficiently careful about what email they let out from their > servers with their domain in Mail From, so this isn't a DKIM unique issue. This is what makes me think you’re not understanding the actual issue here. It is a DKIM unique issue. The ESPs can see, control and manage the mail using their servers. They will block, shut off and otherwise disrupt the flow of spam coming out of their system. In the case we’re discussing here, the message isn’t going out through their system, so they have no control. > Ultimately, I don't think senders should DKIM sign mail they aren't willing > to > take responsibility for, since that's exactly what a DKIM signature is > supposed to signify. They took responsibility for the single opt-in message that was sent through their system. I’m not sure they have any responsibility for the million copies of the message the recipient sends through a different infrastructure. Unless you’re saying that DKIM signatures should only be assigned to mail that has been manually reviewed by the infrastructure host? laura -- 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] DKIM reply mitigations: re-opening the DKIM working group
> On 10 Nov 2022, at 13:24, Murray S. Kucherawy wrote: > > [offlist] > > On Thu, Nov 10, 2022 at 1:21 PM Laura Atkins <mailto:la...@wordtothewise.com>> wrote: > >> On 10 Nov 2022, at 13:17, Murray S. Kucherawy > <mailto:superu...@gmail.com>> wrote: >> >> On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins > <mailto:la...@wordtothewise.com>> wrote: >> In many cases, the reason the mail isn’t going out through the signing >> domain is because the signing domain’s anti-spam heuristics are good enough >> that the sender couldn’t maintain an account there long enough to send out >> any volume of email. That’s why the domain has a good reputation - because >> they block spam off their network. This is a way to steal the good >> reputation from the good ESP. >> >> Interesting. Almost seems like "SPF against the signing domain" could be a >> win, except for all the usual forwarding concerns. > > I think a lot of it is being blocked and the receiving orgs are aware it’s > happening and the replays are not contributing that much to the actual > reputation of the originating domain. Certainly, what I’m hearing from the > folks who are being used as the signer for the replay is they’re not seeing a > whole lot of impact on delivery and reputation. > > Am I reading this right, i.e., you think this is mostly a non-issue because > it's easy to spot and filter? I think it’s not an issue for deliverability for the forged domain. (Remember: my opinions are filtered through the deliverability lens). I also think that the practical solutions applied by the big filters (using the tuple of SPF domain, DKIM domain and 5322.from domain as the identity for the message; noting normal patterns of delivery for a particular d=; enforcing RFC compliance on the incoming mail) are outpacing any changes to the standard that we might have. I don’t know if they have an appetite to implement a new or extended standard that is supposed to fix a problem that they have already (mostly) solved. I think there is space to have the discussion - is this something that needs a standard change / update? Are there other things we want to address? But I’m also thinking we need to engage with the mailbox providers to get their viewpoints on it. laura -- 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] DKIM reply mitigations: re-opening the DKIM working group
> On 10 Nov 2022, at 13:17, Murray S. Kucherawy wrote: > > On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins <mailto:la...@wordtothewise.com>> wrote: > In many cases, the reason the mail isn’t going out through the signing domain > is because the signing domain’s anti-spam heuristics are good enough that the > sender couldn’t maintain an account there long enough to send out any volume > of email. That’s why the domain has a good reputation - because they block > spam off their network. This is a way to steal the good reputation from the > good ESP. > > Interesting. Almost seems like "SPF against the signing domain" could be a > win, except for all the usual forwarding concerns. I think a lot of it is being blocked and the receiving orgs are aware it’s happening and the replays are not contributing that much to the actual reputation of the originating domain. Certainly, what I’m hearing from the folks who are being used as the signer for the replay is they’re not seeing a whole lot of impact on delivery and reputation. > 2) The messages often have two different To: lines > > This violates RFC 5322, so it would be easy to filter these out, except that > we would need to know how common and tolerated this is today among legitimate > messages. Yup. I believe replay attacks are one of the things driving the current increase in ’this message violates the RFCs, fix your stuff and try again later’ rejections by the big mailbox providers. -- 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] DKIM reply mitigations: re-opening the DKIM working group
orts fail before due to a lack of consensus >>> on >>> the exact problem (DBOUND comes immediately to mind). >>> >>> Even if there's no report, I think we should make sure we understand the >>> problem first. >>> >>> Would someone who's pushing for a solution please describe what's being >>> done >>> that's technically distinguishable from something like traditional email >>> forwarding (e.g. using may alumni.example.edu address and then >>> alumni.example.edu forwards it to my current "real" address). By design, >>> DKIM >>> has no problem with this behavior, so I'd like to understand how to >>> distinguish good from bad in this space. >>> >>> Scott K >>> >>> On Wednesday, November 9, 2022 12:43:35 PM EST Barry Leiba wrote: >>>> Is this relevant to the charter? Do you doubt the attacks >>>> sufficiently that you would want to object to chartering a working >>>> group to address the issue? >>>> >>>> Barry >>>> >>>> On Wed, Nov 9, 2022 at 4:54 PM Alessandro Vesely wrote: >>>>> On Wed 09/Nov/2022 13:08:15 +0100 Barry Leiba wrote: >>>>>> [...] >>>>>> >>>>>> 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 will start by considering those proposals; other >>>>>> proposals remain welcome. >>>>> >>>>> Isn't there a report on relevant replay attacks? All the above I-D >>>>> say >>>>> that replay attacks are a problem. Bron adds that the attack was >>> >>> widely >>> >>>>> seen in early 2022. However, there's not a panoramic view of the >>>>> problem, mentioning volume, scope, targets and such. >>>>> >>>>> I know replay attacks are possible, but I never saw one. >>>>> >>>>> >>>>> Best >>>>> Ale >>>>> -- >>>>> >>>>> >>>>> >>>>> >>>>> ___ >>>>> Ietf-dkim mailing list >>>>> Ietf-dkim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-dkim >>>> >>>> ___ >>>> Ietf-dkim mailing list >>>> Ietf-dkim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-dkim >>> >>> ___ >>> Ietf-dkim mailing list >>> Ietf-dkim@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-dkim > > > > > ___ > 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] Looking for a little help testing DKIM failure reports, thank you.
t; > How often are the failure reports generated ? did not see that mentioned in > the RFC’s ? > > Does anyone see anything obvious that I am doing wrong ? > Thank you. > > > -ANGELO FAZZINA > > ITS Service Manager: > Spam and Virus Prevention > Mass Mailing > G Suite/Gmail > > ang...@uconn.edu <mailto:ang...@uconn.edu> > University of Connecticut, ITS, SSG, Server Systems > 860-486-9075 > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org <mailto:Ietf-dkim@ietf.org> > https://www.ietf.org/mailman/listinfo/ietf-dkim > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fietf-dkim=02%7C01%7Cangelo.fazzina%40uconn.edu%7Cd11a679d2df74fbeb63908d664418541%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C636806629916334604=oYg%2BrdpATbemNnI6afrabJYGmtuvJJZ6gSAbr%2Bd2Yeo%3D=0>___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org <mailto:Ietf-dkim@ietf.org> > https://www.ietf.org/mailman/listinfo/ietf-dkim > <https://www.ietf.org/mailman/listinfo/ietf-dkim> -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
