Re: [Ietf-dkim] Welcome to the rechartered working group
Mainframes are part of computing history too but there’s more than one of them in production as we speak. If there is no protocol and only a best practice solution then so be it. --srs From: Ietf-dkim on behalf of Michael Thomas Sent: Monday, March 20, 2023 1:04 AM To: ietf-dkim@ietf.org Subject: Re: [Ietf-dkim] Welcome to the rechartered working group As far as coupling the envelope and body, that seems extremely likely to suffer from the law of unintended consequences. Frankly, as I wrote in my piece on throwing my hands up on mailing lists, the actual solution is to move to a non-email protocol since email is and will be forevermore broken wrt to authentication. It is not an eventuality that email must be the underlying transport for forum-like messaging. There is no particular necessity for email's distributed characteristic to run one. Mailing lists are mainly historical, imo. Mike ___ 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
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 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
Re: [Ietf-dkim] Welcome to the rechartered working group
On 3/19/23 11:57 AM, Wei Chuang wrote: On Tue, Mar 7, 2023 at 4:10 AM Laura Atkins wrote: ... 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. Agreed for the most part. While we can get mileage with the existing RFC6376 based tools such as header oversigning, "x=" expiry, and the other techniques mentioned, at some point the spammers will adapt. And as Michael and the panelist have pointed out, RFC6376 inherently permits DKIM replay as a feature due to that separation between envelope and message. The main thing I would quibble with the panelist is the distinct break if we start validating parts of the envelope or interacting with transport, as whatever technique to be adopted will have to consider participation by unaware forwarders i.e. some sort of gradual adoption process likely with some sort of experiment. Also I would argue we should break that wall between the message and the envelope and transport. From where I sit, I see mail forwarding bit by bit breaking as spammers use forwarding as a general technique, and the mitigations put in place using the existing protocols are insufficient for the challenge. The evidence is anecdotal since there aren't great tools to look at this at scale. It should be noted that what DKIM says as a /protocol/ and what the receiver considers as a spam filtering MTA are not the same. DKIM rightfully has nothing to say about the envelope because it's not part of its bailiwick. That doesn't mean a receiver can't use the envelope for clues about spamminess. Spam filters are inherently heuristics while DKIM is deterministic. As far as coupling the envelope and body, that seems extremely likely to suffer from the law of unintended consequences. Frankly, as I wrote in my piece on throwing my hands up on mailing lists, the actual solution is to move to a non-email protocol since email is and will be forevermore broken wrt to authentication. It is not an eventuality that email must be the underlying transport for forum-like messaging. There is no particular necessity for email's distributed characteristic to run one. Mailing lists are mainly historical, imo. Mike ___ 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 March 19, 2023 6:57:13 PM UTC, Wei Chuang wrote: >On Tue, Mar 7, 2023 at 4:10 AM Laura Atkins wrote: > >> ... >> 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. >> > >Agreed for the most part. While we can get mileage with the existing >RFC6376 based tools such as header oversigning, "x=" expiry, and the other >techniques mentioned, at some point the spammers will adapt. And as >Michael and the panelist have pointed out, RFC6376 inherently permits DKIM >replay as a feature due to that separation between envelope and message. >The main thing I would quibble with the panelist is the distinct break if >we start validating parts of the envelope or interacting with transport, as >whatever technique to be adopted will have to consider participation by >unaware forwarders i.e. some sort of gradual adoption process likely with >some sort of experiment. Also I would argue we should break that wall >between the message and the envelope and transport. From where I sit, I >see mail forwarding bit by bit breaking as spammers use forwarding as a >general technique, and the mitigations put in place using the existing >protocols are insufficient for the challenge. The evidence is anecdotal >since there aren't great tools to look at this at scale. If we're going to deprecate indirect mail flows we should be explicit about it. Standardizing protocol changes that make them look inherently suspicious while pretending that they are still supported is disingenuous and not the way to go about it. As far as I have seen, none of the proposals that break the boundary between envelope and the message body can distinguish between 'good' and 'bad' indirect mail. I do think we should, for the moment, continue to focus on the problem statement to see if we can come up with a technically distinct definition of the problem. Scott K ___ 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 Tue, Mar 7, 2023 at 4:10 AM Laura Atkins wrote: > ... > 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. > Agreed for the most part. While we can get mileage with the existing RFC6376 based tools such as header oversigning, "x=" expiry, and the other techniques mentioned, at some point the spammers will adapt. And as Michael and the panelist have pointed out, RFC6376 inherently permits DKIM replay as a feature due to that separation between envelope and message. The main thing I would quibble with the panelist is the distinct break if we start validating parts of the envelope or interacting with transport, as whatever technique to be adopted will have to consider participation by unaware forwarders i.e. some sort of gradual adoption process likely with some sort of experiment. Also I would argue we should break that wall between the message and the envelope and transport. From where I sit, I see mail forwarding bit by bit breaking as spammers use forwarding as a general technique, and the mitigations put in place using the existing protocols are insufficient for the challenge. The evidence is anecdotal since there aren't great tools to look at this at scale. -Wei smime.p7s Description: S/MIME Cryptographic Signature ___ 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 3/19/23 10:08 AM, Wei Chuang wrote: * DKIM replay was considered during development of RFC- hence the "x=" tag Considering that x= was mine from the beginning, I can say without question that replay wasn't what I had in mind. I always considered the replay problem to be bogus since "replay" is a perfectly legitimate use of email. It was more of "I don't want to take responsibility for this infinitely". That said, there were tons of people -- many who still participate on this list -- who were against it. Mike ___ 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
I was one of the M3AAWG 57 SF DKIM replay session organizers that helped put together the slides, so I can try to summarize some of the things in the slides. (I was hit with Covid so couldn't attend in person) M3AAWG has a confidentiality policy to permit greater knowledge sharing among participants so I will be sensitive and respectful of those concerns. So I apologize if I leave something out, but it might be because something was indeed sensitive or I suspect it is, and of course I missed the actual session, so don't know what was said in person. The following is a high level outline of the slides/talk: - Introduction and description of DKIM replay noting the False-Negative and False Positive effects on reputation systems - Description of DKIM Replay detection techniques and effects observed by senders and receivers - Summary of existing DKIM replay mitigations based on tools available in RFC6376 - DKIM development history wrt DKIM Replay - M3AAWG 56 Brooklyn BoF / IETF 115 Dispatch proposals - Recipient in the signature proposals/drafts - Gather per-hop signatures proposals/drafts - Problem statement draft The session reuses some of the IETF 115 Dispatch DKIM Replay slides i.e. the introduction and proposals, meaning you can find the content there. Some interesting points: - Several senders described using Gmail Postmaster Tools for detection of DKIM replay - to look for changes to reputation, user reported spam, and volume - Summary of existing DKIM replay mitigations based on tools available in RFC6376 - DKIM header oversigning. Some discussion on which headers. - DKIM timestamp and expiry. Discussion of expiry durations. - Signature counting. Acknowledged False Positives which needs support to mitigate, but the claim is DKIM replay isn't a problem for that receiver i.e. highly successful. - Key rotation - DKIM replay was considered during development of RFC- hence the "x=" tag - Advice for DKIM WG success? To encourage folks to participate in the mailing list discussion thanks, -Wei On Tue, Mar 7, 2023 at 4:10 AM Laura Atkins 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
