Re: [Ietf-dkim] DKIM Signature
It appears that Scott Kitterman said: >On October 27, 2023 2:56:30 PM UTC, "Murray S. Kucherawy" > wrote: >>On Sun, Oct 1, 2023 at 1:50 AM Jan Dušátko >>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
Re: [Ietf-dkim] DKIM Signature
On October 27, 2023 2:56:30 PM UTC, "Murray S. Kucherawy" wrote: >On Sun, Oct 1, 2023 at 1:50 AM Jan Dušátko >wrote: > >> I would like to ask to consider the possibility of defining a DKIM >> signature using Ed448. [...] > > >Which DKIM implementations are known to be willing to support this if it >were added? > >ED25519 support was added by a working group called DCRUP. Although that >WG has since closed, the list is still open and you could try posting there >to see if there's interest. > >I don't think there are any working groups currently operating whose >charters include taking up work like this. The registry rules require an >RFC with IETF Consensus, which would mean either a working group or >sponsorship of an Area Director. You would just need to produce a short >document like RFC 8463 to get this done. 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. Given the small uptake in ed25119, I'm very unlikely to invest time in implementing yet another crypto algorithm unless it's needed because of known RSA/ed25119 issues. We don't need to hedge the hedge while the primary algorithm (RSA) is fine. Maybe someday, but almost certainly not something I'd implement in the foreseeable future. Scott K ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
On 27/10/2023 15:56, Murray S. Kucherawy wrote: Which DKIM implementations are known to be willing to support this if it were added? If I saw interest, I'd be willing to add it to Exim. -- Cheers, Jeremy ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
On Sun, Oct 1, 2023 at 1:50 AM Jan Dušátko wrote: > I would like to ask to consider the possibility of defining a DKIM > signature using Ed448. [...] Which DKIM implementations are known to be willing to support this if it were added? ED25519 support was added by a working group called DCRUP. Although that WG has since closed, the list is still open and you could try posting there to see if there's interest. I don't think there are any working groups currently operating whose charters include taking up work like this. The registry rules require an RFC with IETF Consensus, which would mean either a working group or sponsorship of an Area Director. You would just need to produce a short document like RFC 8463 to get this done. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] [Lists] DKIM Working Group Status Update
On Fri, Oct 27, 2023 at 6:33 AM wrote: > Appreciate all the work and effort you’ve put into this. I would like to > help out as much as I can. I know Monitoring isn’t part of this from IETF > POV, however, I think it’s something that is important and I will bring > this up on the M3AAWG side. > Please don't discount the IETF's interest in measurement too quickly. Actual operating experience (represented by data) is far more persuasive than opinion a lot of the time when it comes to shaping protocols. "Data, data, data! I cannot make bricks without clay." -- from the works of Sir Arthur Conan Doyle -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Working Group Status Update
On Thu, Oct 26, 2023 at 12:03 PM Wei Chuang wrote: > I was there at M3AAWG and concur with the chair's observations. I should > also note I was part of the group who proposed restarting the DKIM WG at > Dispatch IETF-115. My hope back then was that solving DKIM replay > systematically could be a starting point for resolving more general email > authentication problems that to me seems to be the root cause of the > unresolved conflict in the DMARCbis WG. As such I'm saddened if this group > concludes with just documenting a set of best practices to mitigate DKIM > replay, as I don't feel this systematically resolves the authentication > issues such as DKIM replay that I see today. Just before M3AAWG, I saw > spammers had a campaign that used a combination of DKIM replay plus SPF > upgrade. Going forward I suspect the spammers will keep using creative > combinations of attacks driven by the Darwinian evolution afforded by the > whack-a-mole approach we're stuck with. > I don't get the impression that the community as a whole currently has the energy to tackle even smaller problems, much less things of the size you're proposing here. Some of that might be the fact that these days we are generally hacking on problems for which convergence turns out to be extremely difficult, and we're all tired. But DKIM and DMARC are not the only places where this is true; my impression is also that EMAILCORE is largely dormant lately. The place where any momentum seems to exist is over in JMAP and EXTRA, but they're not working on authentication at all. Still, I would be happy to be proven wrong, and maybe you can collect or develop momentum for a broader effort. There's no harm in trying. I would argue though that the bar is a little higher for such a thing because we've seen time and again a pattern of a lot of energy to charter and then no energy to actually do work. My fear is that this will lead to large operators calling the shots rather than the community, which often doesn't lead to the best outcomes. So if I can do anything to help develop and sustain such a community, I'm interested. -MSK, wearer of hats ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] [Lists] DKIM Working Group Status Update
Laura, Appreciate all the work and effort you’ve put into this. I would like to help out as much as I can. I know Monitoring isn’t part of this from IETF POV, however, I think it’s something that is important and I will bring this up on the M3AAWG side. I am happy to share on the thing we have done. We might be in a more of unique scenario than most, I work for an ESP that is built on-top of Cloud ESPs as well as its own into MTA Pipeline. So the fun tidbits of that is we don’t always have the control we’d like to fight this or prevent this with every vendor we use upstream. Due to this, I will only really comment on what we have done with our internal MTA Pipeline since we can control that. The biggest thing we have done, like most is over signing, we today even if not present will over sign a blank field and we will sign an additional blank field for specific fields that we deem as “important”. RE: What effects? I think the biggest thing from my POV is the hit on the reputation it has. This not only have impacts on successful acceptance/inbox placement, but could lead to a poor image for the brand itself. Someone receives egregious affiliate marketing from i.e. Lowes, but it’s really not from them, that could make someone no longer shop at Lowes. Francis > On Oct 26, 2023, at 6:47 AM, Laura Atkins wrote: > > > Hello, All > > To remind folks where the group is, we currently have a problem statement > that needs to be discussed so we can reach consensus to adopt it. This > requires participation from members of this list. The current problem > statement is available at: > https://datatracker.ietf.org/doc/draft-ietf-dkim-replay-problem/ > > Per the charter (https://datatracker.ietf.org/wg/dkim/about/) the consensus > problem statement was due to be filed in the datatracker in April. It’s now > October and we’ve had no real discussion about the problem statement for > months. I think it’s fair to say this group has stalled. There doesn’t seem > to be any real interest in working on this problem. > > As much of the initial impetus for the group came out of discussions at a > M3AAWG meeting, I asked for a session during the most recent meeting (October > 2023, Brooklyn) to discuss whether or not there was enough interest to move > the IETF group forward. I asked for, and was granted, permission to report > back on the session here. > > My primary goal for the session was: > Determine if there is a critical mass of people willing to commit to moving > the working group forward and if so > Get firm commitments from individuals about what they can do for the process > Collaboratively develop a plan of action on getting this done > > If there was not a critical mass of people willing to commit to moving the > group forward, then I would take that into consideration and work with the > IETF. Any remaining session time would be focused on what MAAWG could do to > address the issue. > > I started off by asking the group if there was any confusion about what the > problem was. I then read my definition of a DKIM replay attack to ensure we > were all on the same page. > > “A DKIM replay attack is one where a bad actor sends a single message through > a high reputation system, gets a DKIM signature to a mailbox they control. > They then take that message and resend it, unchanged, through a system they > control that does not add a DKIM signature. This message carries the original > system’s high reputation d= value and may receive better delivery due to > that.” > > Members in the room added additional reasons for DKIM replay attack: > Damage the sender’s reputation > Inflict damage on the sender’s infrastructure (not removing List-Unsub > headers can generate significant traffic on a sender’s unsubscribe > infrastructure, for instance) > Use the sender’s reputation to warm up new infrastructure controlled by the > attacker > > With most of the room agreeing these were the issues and problems, I asked > for a show of hands for who was willing to commit to coming to this working > group and participating. There were approximately 8 hands raised out of a > room of approximately 50 participants. > > It was my opinion 8 people does not constitute a critical mass of people to > move the working group forward and I said so. The IETF area director, who was > at the meeting, asked the group if they were happy about only 8 people making > the decisions for them. > > There was a discussion about next steps. Individuals working for some large > providers (both on the sending bulk mail side and on the large receiving mail > side) indicated they thought the problem was mostly mitigated by things they > implemented on their end. Other individuals discussed potential problems and > fixes. > > I then called for a rough consensus for a path forward of finishing the > problem statement, documenting the problem and some of the solutions folks > have im
