Re: [Ietf-dkim] Rechartering
On 1/5/2023 9:20 AM, Alessandro Vesely wrote: How about "replay-resistant protocol"? btw, it isn't clear that 'protocol' is what a solution will be. might be. might not. might be purely operational conventions, for example. 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] Rechartering
On 1/5/23 10:17 AM, Wei Chuang wrote: On Thu, Jan 5, 2023 at 10:06 AM Michael Thomas wrote: On 1/5/23 9:20 AM, Alessandro Vesely wrote: > On Thu 05/Jan/2023 17:33:36 +0100 Murray S. Kucherawy wrote: >> I've added a few proposed milestones with dates > > I wouldn't call "replay-resistant DKIM enhancement(s)" the > deliverable. I understand the WG name is DKIM, but two of the > proposed drafts don't even mention it. We may call ARC a "kind of > DKIM", but a solution based on it would be better called an ARC > enhancement, no? > > How about "replay-resistant protocol"? > Sorry, ARC is a failed experiment that doesn't deliver what it was supposed to deliver. I disagree that it's a failed experiment. We're using ARC results for forwarders who choose to generate them. Well, it doesn't do what it was purported to do. That and it doesn't do anything that DKIM couldn't do in the first place since nobody can say why the seal is actually needed. The DKIM wg should have no part of it. It should be completely out of scope. I agree with Alessandro's proposed language change that allows for ARC. Moreover ARC is subject to the same replay issue as DKIM and needs some sort of fix. DKIM is a full internet standard and ARC is an experiment. This is the DKIM wg. ARC had no problem copying the DKIM output. Nothing that happens here will change that. It's bad enough that this wg is considering doing unnatural acts with the envelope, it would be even worse to require it down a rat hole of a failed experiment. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] Yet another draft
Here's another idea to tell legitimate vs. abusive forwarding: https://datatracker.ietf.org/doc/draft-vesely-email-agreement/ Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On 1/5/2023 11:03 AM, Wei Chuang wrote: 1. The motivation for the current effort has been exploitation of re-posting to exploit a DKIM reputation. 2. Are there any other kinds of replay scenarios that are an issue now? I suspect there aren't. While not exactly ARC replay, we've seen recently that spammers are exploring munging the ARC headers. One campaign had them swapping a complete ARC header set into another message. In another they added an incomplete set. Consequently we're worried about the spammers exploiting ARC vulnerabilities. There are some possibilities this suggests. 1. We could seek to explore and counter-act all (or a wide range) of replay scenarios, independent of their type or actual presence. That is, both replays that are present in the wild and replays that are merely deemed possible, no matter how or why they do or might occur. 2. We could focus only on the know replay efforts so far, independent of type or degree of threat. 3. We could focus only on known, significant replay efforts. 4. and so on... Of these, only 4 ensures focused, pragmatic efforts, where there is actual pressure to find a remedy sooner rather than later. The others seem more like research topics. 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] Rechartering
On Thu, Jan 5, 2023 at 10:43 AM Dave Crocker wrote: > On 1/5/2023 9:20 AM, Alessandro Vesely wrote: > > I wouldn't call "replay-resistant DKIM enhancement(s)" the > > deliverable. I understand the WG name is DKIM, but two of the > > proposed drafts don't even mention it. We may call ARC a "kind of > > DKIM", but a solution based on it would be better called an ARC > > enhancement, no? > > > > How about "replay-resistant protocol"? > > Just to explore this a bit further: > > 1. The motivation for the current effort has been exploitation of > re-posting to exploit a DKIM reputation. > > 2. Are there any other kinds of replay scenarios that are an issue now? > I suspect there aren't. > While not exactly ARC replay, we've seen recently that spammers are exploring munging the ARC headers. One campaign had them swapping a complete ARC header set into another message. In another they added an incomplete set. Consequently we're worried about the spammers exploiting ARC vulnerabilities. -Wei > 3. Whatever mechanisms are developed to prevent or mitigate replay, > their current use will be to deal with a DKIM-related replay problem. > > It's likely to be useful for the working group name to relate to a > specific, real and current problem, even if a technical solution doesn't > explicitly deal with the technical details of that problem. > > 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 > 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] Rechartering
On 1/5/2023 9:20 AM, Alessandro Vesely wrote: I wouldn't call "replay-resistant DKIM enhancement(s)" the deliverable. I understand the WG name is DKIM, but two of the proposed drafts don't even mention it. We may call ARC a "kind of DKIM", but a solution based on it would be better called an ARC enhancement, no? How about "replay-resistant protocol"? Just to explore this a bit further: 1. The motivation for the current effort has been exploitation of re-posting to exploit a DKIM reputation. 2. Are there any other kinds of replay scenarios that are an issue now? I suspect there aren't. 3. Whatever mechanisms are developed to prevent or mitigate replay, their current use will be to deal with a DKIM-related replay problem. It's likely to be useful for the working group name to relate to a specific, real and current problem, even if a technical solution doesn't explicitly deal with the technical details of that problem. 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] Rechartering
On Thu, Jan 5, 2023 at 10:06 AM Michael Thomas wrote: > > On 1/5/23 9:20 AM, Alessandro Vesely wrote: > > On Thu 05/Jan/2023 17:33:36 +0100 Murray S. Kucherawy wrote: > >> I've added a few proposed milestones with dates > > > > I wouldn't call "replay-resistant DKIM enhancement(s)" the > > deliverable. I understand the WG name is DKIM, but two of the > > proposed drafts don't even mention it. We may call ARC a "kind of > > DKIM", but a solution based on it would be better called an ARC > > enhancement, no? > > > > How about "replay-resistant protocol"? > > > Sorry, ARC is a failed experiment that doesn't deliver what it was > supposed to deliver. I disagree that it's a failed experiment. We're using ARC results for forwarders who choose to generate them. > The DKIM wg should have no part of it. It should be > completely out of scope. > I agree with Alessandro's proposed language change that allows for ARC. Moreover ARC is subject to the same replay issue as DKIM and needs some sort of fix. -Wei > > Mike > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim > 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] Rechartering
On 1/5/23 9:20 AM, Alessandro Vesely wrote: On Thu 05/Jan/2023 17:33:36 +0100 Murray S. Kucherawy wrote: I've added a few proposed milestones with dates I wouldn't call "replay-resistant DKIM enhancement(s)" the deliverable. I understand the WG name is DKIM, but two of the proposed drafts don't even mention it. We may call ARC a "kind of DKIM", but a solution based on it would be better called an ARC enhancement, no? How about "replay-resistant protocol"? Sorry, ARC is a failed experiment that doesn't deliver what it was supposed to deliver. The DKIM wg should have no part of it. It should be completely out of scope. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On Thu 05/Jan/2023 17:33:36 +0100 Murray S. Kucherawy wrote: I've added a few proposed milestones with dates I wouldn't call "replay-resistant DKIM enhancement(s)" the deliverable. I understand the WG name is DKIM, but two of the proposed drafts don't even mention it. We may call ARC a "kind of DKIM", but a solution based on it would be better called an ARC enhancement, no? How about "replay-resistant protocol"? Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On Sat, Dec 31, 2022 at 3:02 PM Murray S. Kucherawy wrote: > On Sat, Dec 31, 2022 at 2:43 PM Dave Crocker wrote: > >> The initial effort to form a working group in the IETF was pretty casual >> and surfaced a lack of sufficient consensus among advocates. The IETF >> said go away until there's more agreement. >> >> We went away for a year, during which we developed the original version >> of DKIM, which demonstrated the coherence. >> >> The current effort has none of that existing critical mass of work and >> agreement. This makes the effort quite a lot riskier. >> >> The fact that things are taking quite a few months doesn't help. >> > > That's true. I'd forgotten this bit of the history. > > If we think this constraint is appropriate, I'm fine to include it. Does > someone want to propose a sentence or two? I need to avoid getting my > wrist slapped for both championing the charter and writing it. > The IESG approved the proposed charter to go out for external review. I've added a few proposed milestones with dates (these can be edited later) and taken a run at editing the text to add the constraints people were proposing. Please review and let me know if I got it wrong or missed any feedback, or if the dates on the milestones are not realistic. They were selected on the assumption that we charter and have co-chairs in place by the end of January. https://datatracker.ietf.org/doc/charter-ietf-dkim/ Lastly, I have one co-chair volunteer, but I need a second, preferably someone who has chaired something in the IETF before. Please let me know if you'd like to either volunteer or nominate someone. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
