Took a moment to go over this purported problem with replays: 1.1. The problem
Since many domains (including those of bad actors) list DKIM records, receiving systems track the history of messages using a DKIM-based domain name, to formulate a reputation for the name, and then to classify incoming emails. The way this is phrased suggest it is a common practice for a receiving system to “track the history of messages using a DKIM-based domain name.” I’m not doing any such thing nor is any installation of our package. What domain(s) or package(s) are doing this? As I read more, I believe too much stake is put on reputation which causes a heighten concern for a self-created problem by an ESP. While an ESP may be considered “High Value” as an enterprise, i.e. gmail.com, by no means, is the domain “reputation” is “good” as “high”. I don’t consider any ESP domain having a level of good reputation purely based their domain name. I am leaning towards this is not a DKIM issue. It’s an ESP issue. They need to deal with the potentials of malicious users. Since day one, DKIM was about establishing a technical method to prove authentication by keeping message integrity intact. When verification deviated, a point of failure and possible actions was considered using a DKIM Policy Add-on, not a Reputation Protocol add-on simply because there are none (standard method). Unfortunately we removed SSP (which was built into DKIM), separated as ADSP and replaced with very poor substitute DMARC and we continue to have issues with 3rd party signature models. The concerns about ESP reputation replay abuse is because they have a proprietary DKIM domain-based method for reputation. This can be addressed but it requires a greater adoption of a DKIM Policy Protocol that is above and beyond what DMARC offers with its limited concepts and crippling alignment restraints. In short, DKIM is fine. Only a system using a proprietary reputation model based on its ESP domain has a higher replay problem. Systems that do not use a reputation model do not have this problem. But, via POLICY if the domain using reputation wishes a verifier to put more restrictions on a received signed domain, i.e. enforce `x=` expiration tag, I am all for it. Thanks Hector Santos CEO/CTO Santronics Software, Inc. > On Mar 7, 2023, at 7:09 AM, Laura Atkins <la...@wordtothewise.com> wrote: > > 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
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
