Re: [Ietf-dkim] Welcome to the rechartered working group
On 3/22/23 4:00 PM, Emanuel Schorsch wrote: On Wed, Mar 22, 2023 at 11:29 AM Murray S. Kucherawy wrote: On Sun, Mar 19, 2023 at 11:04 PM Emanuel Schorsch wrote: In my mind, there are two important things I would like to see achieved: 1) Distinguish indirect from direct flows (encode in some way which server / mailingList the original DKIM message was intended to come from). This is needed for domains that aren't easily identifiable as direct flows (SPF isn't aligned by DKIM in the direct case). Wasn't ARC meant to solve this? What have the results been? ARC has the same challenge that DKIM has when it comes to replay. How do I know if this is direct mail or indirect mail? Which set of IPs should I expect the direct mail to be sent from? ARC allows forwarders to record/preserve authentication status but the same valid ARC headers can be sent millions of times from all kinds of different servers. Note that DKIM has been able to sign auth-res from the very beginning. Which is why ARC getting inserted into discussions like this is both frustrating and just muddies the waters. 2) Give more info to identify benign indirect flows (E.g. "forwarded on behalf of"). This is helpful for recognizing a recipient's desired indirect flows. I'm pretty sure this is easily spoofed. So is any sort of tagging or header field manipulation mechanism. The spammer just needs to make its mail look sufficiently like something you consider legitimate, and they're in. That is why it would be nice to see a solution less trivially spoofable than existing forwarding headers (e.g. X-Forwarded-For). If, for example, forwarded-for is recorded in the ARC header, then you can restrict yourself to trusting a specific pair of "forwarded-for" and ARC sealer, which is much more trustworthy than the header alone. But, even an easily spoofable header is still useful. Easily spoofable means that it doesn't provide much protection against phishing, but it does make it substantially harder to scale for spam. Most people will have a limited set of sources which they receive indirect mail for, and those will vary widely between people. So if spammers, for the Forwarded-For header, need to get the right value per recipient it makes automating to a huge scale much more difficult. But the spammer can also resign a message to make it look like an indirect flow along with whatever headers you insert. In the end this all boils down to how much you trust the domain sending you the message. For the domain the spammer controls, you'd hope they have a neutral to bad reputation. For legit mailing list providers, you'd hope they would get a positive reputation over time. None of this has anything to do with the problem that ARC purports to solve. 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 Wed, Mar 22, 2023 at 11:29 AM Murray S. Kucherawy wrote: > On Sun, Mar 19, 2023 at 11:04 PM Emanuel Schorsch 40google@dmarc.ietf.org> wrote: > >> In my mind, there are two important things I would like to see achieved: >> >> 1) Distinguish indirect from direct flows (encode in some way which >> server / mailingList the original DKIM message was intended to come from). >> This is needed for domains that aren't easily identifiable as direct flows >> (SPF isn't aligned by DKIM in the direct case). >> > > Wasn't ARC meant to solve this? What have the results been? > ARC has the same challenge that DKIM has when it comes to replay. How do I know if this is direct mail or indirect mail? Which set of IPs should I expect the direct mail to be sent from? ARC allows forwarders to record/preserve authentication status but the same valid ARC headers can be sent millions of times from all kinds of different servers. > > >> 2) Give more info to identify benign indirect flows (E.g. "forwarded on >> behalf of"). This is helpful for recognizing a recipient's desired indirect >> flows. >> > > I'm pretty sure this is easily spoofed. So is any sort of tagging or > header field manipulation mechanism. The spammer just needs to make its > mail look sufficiently like something you consider legitimate, and they're > in. > That is why it would be nice to see a solution less trivially spoofable than existing forwarding headers (e.g. X-Forwarded-For). If, for example, forwarded-for is recorded in the ARC header, then you can restrict yourself to trusting a specific pair of "forwarded-for" and ARC sealer, which is much more trustworthy than the header alone. But, even an easily spoofable header is still useful. Easily spoofable means that it doesn't provide much protection against phishing, but it does make it substantially harder to scale for spam. Most people will have a limited set of sources which they receive indirect mail for, and those will vary widely between people. So if spammers, for the Forwarded-For header, need to get the right value per recipient it makes automating to a huge scale much more difficult. > -MSK > ___ > 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] Welcome to the rechartered working group
On Sun, Mar 19, 2023 at 11:04 PM Emanuel Schorsch wrote: > In my mind, there are two important things I would like to see achieved: > > 1) Distinguish indirect from direct flows (encode in some way which server > / mailingList the original DKIM message was intended to come from). This is > needed for domains that aren't easily identifiable as direct flows (SPF > isn't aligned by DKIM in the direct case). > Wasn't ARC meant to solve this? What have the results been? > 2) Give more info to identify benign indirect flows (E.g. "forwarded on > behalf of"). This is helpful for recognizing a recipient's desired indirect > flows. > I'm pretty sure this is easily spoofed. So is any sort of tagging or header field manipulation mechanism. The spammer just needs to make its mail look sufficiently like something you consider legitimate, and they're in. -MSK ___ 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 Mon 20/Mar/2023 07:04:11 +0100 Emanuel Schorsch wrote: In my mind, there are two important things I would like to see achieved: 1) Distinguish indirect from direct flows (encode in some way which server / mailingList the original DKIM message was intended to come from). This is needed for domains that aren't easily identifiable as direct flows (SPF isn't aligned by DKIM in the direct case). Rather, one could try and rescue the ethical nature of direct flows by understanding the forwarder. Consider, for example, a message where To: or Cc: mention l...@example.net, and there is a signature which has d=example.net, and finally SPF validates example.net too. The flow is indirect, but there's an easy inference in this case. If it is clear why a message was forwarder from the original header recipient to the actual envelope recipient, then it has the same worthiness as if it were direct. 2) Give more info to identify benign indirect flows (E.g. "forwarded on behalf of"). This is helpful for recognizing a recipient's desired indirect flows. In an attempt at classifying indirect flows in order to justify forwarding,I drafted this: https://datatracker.ietf.org/doc/draft-vesely-email-agreement/ The idea is that forwarding requires to set up something where the target email address is explicit. If that is legitimate, it can as well be published. Note that this isn't to say indirect mail would be deprecated. Indeed, it'd be self-contradictory to discuss here a document which deprecates mailing lists. Best Ale -- ___ 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
In my mind, there are two important things I would like to see achieved: 1) Distinguish indirect from direct flows (encode in some way which server / mailingList the original DKIM message was intended to come from). This is needed for domains that aren't easily identifiable as direct flows (SPF isn't aligned by DKIM in the direct case). 2) Give more info to identify benign indirect flows (E.g. "forwarded on behalf of"). This is helpful for recognizing a recipient's desired indirect flows. Note that this isn't to say indirect mail would be deprecated. The goal is to better distinguish the flows so we can have a minimally disruptive response when Replay mitigations are needed. For example, consider the approach of counting MessageIds. This has some side effects on benign mail. The better we can identify the benign cases the easier it is to avoid negatively affecting those even while a DKIM Replay attack is active. On Sun, Mar 19, 2023 at 12:22 PM Scott Kitterman wrote: > > > On March 19, 2023 6:57:13 PM UTC, Wei Chuang 40google@dmarc.ietf.org> 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 > ___ 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
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
Re: [Ietf-dkim] Welcome to the rechartered working group
The reason that I think it would be useful in the problem statement is that it would give a way to get people up to speed. Both of the Problem Statement drafts have text relevant to the topic of solution proposal. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Welcome to the rechartered working group
On 3/10/23 7:54 AM, Scott Kitterman wrote: On Friday, March 10, 2023 9:14:05 AM EST Laura Atkins wrote: 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. My suggestion is plan on both. My takeaway from the rechartering discussions is that if there is a protocol solution to this problem, it will not be simple and will take quite some time to be effective since wide deployment would be needed. As a result, there will be, at best, a significant period of time where whatever mitigations/work- arounds that are available will be needed. I think we should plan on documenting them regardless of the outcome of the protocol solution work. The reason that I think it would be useful in the problem statement is that it would give a way to get people up to speed. Not everybody takes part in closed industry groups so the specifics such that they are public in any form are important if this working group is going achieve anything novel. Considering how aggressive the schedule is, there isn't a lot of time for wheel reinvention. 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 3/10/2023 6:14 AM, Laura Atkins wrote: 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? Does anyone have comments on the substance -- and especially about the differences -- between the two problem statement drafts? Preferences? Disagreements? Suggested wording/content changes? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Welcome to the rechartered working group
On 3/10/23 6:14 AM, Laura Atkins wrote: 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. I'm speaking only of the problem statement draft. Listing off things have already been tried or considered and rejected would shorten the cycle when the next phase starts. And I thought that considering solutions was out of scope, so considering protocol changes would be out of scope too. 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? I sent out a post with about 20 questions several weeks ago and got no response. 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 Friday, March 10, 2023 9:14:05 AM EST Laura Atkins wrote: > > 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. My suggestion is plan on both. My takeaway from the rechartering discussions is that if there is a protocol solution to this problem, it will not be simple and will take quite some time to be effective since wide deployment would be needed. As a result, there will be, at best, a significant period of time where whatever mitigations/work- arounds that are available will be needed. I think we should plan on documenting them regardless of the outcome of the protocol solution work. 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 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
Re: [Ietf-dkim] Welcome to the rechartered working group
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. 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. Mike ___ 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
