Re: [Ietf-dkim] Rechartering

On 1/12/23 10:52 AM, Murray S. Kucherawy wrote: On Mon, Jan 9, 2023 at 12:57 AM Alessandro Vesely wrote: On Thu 05/Jan/2023 22:26:32 +0100 Dave Crocker wrote: > On 1/5/2023 9:20 AM, Alessandro Vesely wrote: >> How about "replay-resistant protocol"? > > btw, it isn't clear

Re: [Ietf-dkim] Rechartering

On Mon, Jan 9, 2023 at 12:57 AM Alessandro Vesely wrote: > On Thu 05/Jan/2023 22:26:32 +0100 Dave Crocker wrote: > > 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. > >

Re: [Ietf-dkim] Rechartering

On 1/9/2023 12:51 AM, Alessandro Vesely wrote: 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, Eh?  You mean

Re: [Ietf-dkim] Rechartering

On Thu 05/Jan/2023 22:26:32 +0100 Dave Crocker wrote: 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. That's

Re: [Ietf-dkim] Rechartering

On Thu 05/Jan/2023 20:35:00 +0100 Dave Crocker wrote: On 1/5/2023 11:03 AM, Wei Chuang wrote:  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

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

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

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

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

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

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 > >

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

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

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

Re: [Ietf-dkim] Rechartering

On 1/3/23 1:55 PM, Wei Chuang wrote: So yes this was discussed and started at a M3AAWG BoF (at M3AAWG 56 in Oct 2022) that discussed DKIM replay.  As by that point there were several drafts with proposed solutions, the suggestion from feedback at the BoF was to send this work to IETF

Re: [Ietf-dkim] Rechartering

On Tue, Jan 3, 2023 at 1:38 PM Todd Herr wrote: > On Tue, Jan 3, 2023 at 4:04 PM Michael Thomas wrote: > >> Yet another reason why I'm skeptical. If there were a viable protocol >> solution to this, why hasn't M3AAWG found it? Why re-spin up a working >> group with a what appears to be a

Re: [Ietf-dkim] Rechartering

On Tue, Jan 3, 2023 at 4:04 PM Michael Thomas wrote: > Yet another reason why I'm skeptical. If there were a viable protocol > solution to this, why hasn't M3AAWG found it? Why re-spin up a working > group with a what appears to be a greenfield solution space if an active > industry working

Re: [Ietf-dkim] Rechartering

On 1/3/23 8:59 AM, Todd Herr wrote: On Mon, Jan 2, 2023 at 3:04 PM Evan Burke wrote: On Sat, Dec 31, 2022 at 10:44 PM Wei Chuang wrote: > I'm worried about duplicating work unnecessarily as the M3AAWG has an email authentication BCP.  If the WG to-be indeed does want to

Re: [Ietf-dkim] Rechartering

On Mon, Jan 2, 2023 at 3:04 PM Evan Burke wrote: > > > On Sat, Dec 31, 2022 at 10:44 PM Wei Chuang 40google@dmarc.ietf.org> wrote: > > I'm worried about duplicating work unnecessarily as the M3AAWG has an > email authentication BCP. If the WG to-be indeed does want to generate the > BCP,

Re: [Ietf-dkim] Rechartering

On Sat, Dec 31, 2022 at 10:44 PM Wei Chuang wrote: > I'm worried about duplicating work unnecessarily as the M3AAWG has an email authentication BCP. If the WG to-be indeed does want to generate the BCP, perhaps the M3AAWG document can be the basis for an IETF document assuming M3AAWG is okay

Re: [Ietf-dkim] Rechartering

On Sat, Dec 31, 2022 at 4:18 PM Michael Thomas wrote: > > On 12/31/22 2:37 PM, Murray S. Kucherawy wrote: > > On Sat, Dec 31, 2022 at 1:09 PM Michael Thomas wrote: > >> >> On 12/29/22 7:20 PM, Murray S. Kucherawy wrote: >> >> On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas wrote: >> >>> >>> >>>

Re: [Ietf-dkim] Rechartering

On 12/31/22 2:37 PM, Murray S. Kucherawy wrote: On Sat, Dec 31, 2022 at 1:09 PM Michael Thomas wrote: On 12/29/22 7:20 PM, Murray S. Kucherawy wrote: On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas wrote: Done, and thanks for that text. One nit, Barry's text

Re: [Ietf-dkim] Rechartering

On 12/31/2022 3:02 PM, Murray S. Kucherawy wrote: 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. Murray, Sorry but I don't know what

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

On 12/31/2022 2:37 PM, Murray S. Kucherawy wrote: I take as evidence of this the fact that the first incarnation of the DKIM working group knew itself well enough to completely avoid the topic of user interfaces, for example. The initial effort to form a working group in the IETF was pretty

Re: [Ietf-dkim] Rechartering

On Sat, Dec 31, 2022 at 1:09 PM Michael Thomas wrote: > > On 12/29/22 7:20 PM, Murray S. Kucherawy wrote: > > On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas wrote: > >> >> >> Done, and thanks for that text. >> >> One nit, Barry's text should be above the proposals not below. It makes >> it look

Re: [Ietf-dkim] Rechartering

On 12/29/22 7:20 PM, Murray S. Kucherawy wrote: On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas wrote: Done, and thanks for that text. One nit, Barry's text should be above the proposals not below. It makes it look like those are the only proposals on the table which I'm

Re: [Ietf-dkim] Rechartering

On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas wrote: > > > Done, and thanks for that text. > > One nit, Barry's text should be above the proposals not below. It makes it > look like those are the only proposals on the table which I'm nearly > certain is not your intent. > One other thing

Re: [Ietf-dkim] Rechartering

On 12/25/22 7:55 AM, Murray S. Kucherawy wrote: On Sun, Dec 25, 2022 at 6:31 AM Barry Leiba wrote: I agree with Mike and Scott on the point that it’s worth explicitly allowing the result to be a “can’t do it” publication.  Implicit “couldn’t do it” is fine in most cases, but here

Re: [Ietf-dkim] Rechartering

On Sun, Dec 25, 2022 at 6:31 AM Barry Leiba wrote: > I agree with Mike and Scott on the point that it’s worth explicitly > allowing the result to be a “can’t do it” publication. Implicit “couldn’t > do it” is fine in most cases, but here we might say something like, “If the > working group

Re: [Ietf-dkim] Rechartering

I agree with Mike and Scott on the point that it’s worth explicitly allowing the result to be a “can’t do it” publication. Implicit “couldn’t do it” is fine in most cases, but here we might say something like, “If the working group decides that none of the proposed approaches will work acceptably

Re: [Ietf-dkim] Rechartering

On 12/24/22 1:08 PM, Scott Kitterman wrote: On December 24, 2022 8:22:45 PM UTC, Michael Thomas wrote: On 12/23/22 10:25 PM, Murray S. Kucherawy wrote: On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas wrote: Shouldn't the problem statement explore whether there is a plausible

Re: [Ietf-dkim] Rechartering

On December 24, 2022 8:22:45 PM UTC, Michael Thomas wrote: > >On 12/23/22 10:25 PM, Murray S. Kucherawy wrote: >> On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas wrote: >> >> Shouldn't the problem statement explore whether there is a >> plausible tractable solution before it moves on

Re: [Ietf-dkim] Rechartering

On 12/23/22 10:25 PM, Murray S. Kucherawy wrote: On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas wrote: Shouldn't the problem statement explore whether there is a plausible tractable solution before it moves on to protocol work? That is, if there isn't a tractable solution the wg

Re: [Ietf-dkim] Rechartering

On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas wrote: > Shouldn't the problem statement explore whether there is a plausible > tractable solution before it moves on to protocol work? That is, if there > isn't a tractable solution the wg should go into hibernation again. I'm > pretty sure that I

Re: [Ietf-dkim] Rechartering

On 12/23/2022 11:38 AM, Murray S. Kucherawy wrote: Having heard no further feedback, I've moved the draft charter to the next state, which will trigger the first of two IESG reviews early in the new year.  It will go out for full IETF review after it passes the first of those. The draft

Re: [Ietf-dkim] Rechartering

On 12/23/22 11:38 AM, Murray S. Kucherawy wrote: On Sun, Dec 11, 2022 at 7:25 PM Murray S. Kucherawy wrote: I've synthesized the feedback to date into a new update to the charter text.  It calls out the order of operations the group seems to prefer, and makes explicit the

Re: [Ietf-dkim] Rechartering

On Sun, Dec 11, 2022 at 7:25 PM Murray S. Kucherawy wrote: > > I've synthesized the feedback to date into a new update to the charter > text. It calls out the order of operations the group seems to prefer, and > makes explicit the possible output of a "best practices" update. Let me > know if

Re: [Ietf-dkim] Rechartering

On Thu, Dec 8, 2022 at 11:52 AM Jim Fenton wrote: > > >> I think a checkpoint / review is a good goal for the group. > >> > > > > This seems like something reasonable and easy to add. > > > > Any objections? > > I’m fine if the revision to best practices is scoped to the replay > problem. This

Re: [Ietf-dkim] Rechartering

On 8 Dec 2022, at 7:25, Murray S. Kucherawy wrote: > On Thu, Dec 8, 2022 at 12:56 AM Laura Atkins > wrote: > >> >> Fair enough. Does the charter need to say that a revision to best >> practices, relative to the replay problem, might be a possible output? >> It's within the realm of possibility

Re: [Ietf-dkim] Rechartering

On Thu, Dec 8, 2022 at 12:56 AM Laura Atkins wrote: > > Fair enough. Does the charter need to say that a revision to best > practices, relative to the replay problem, might be a possible output? > It's within the realm of possibility that no protocol work comes out of > this, but a "checkpoint"

Re: [Ietf-dkim] Rechartering

> On 8 Dec 2022, at 00:26, Murray S. Kucherawy wrote: > > On Wed, Dec 7, 2022 at 2:06 PM Dave Crocker > wrote: > As appealing as the AS concept is, I've never been clear how operationally > useful they are. > More to the current point, if the anti-replay work to be

Re: [Ietf-dkim] Rechartering

On 12/7/22 4:26 PM, Murray S. Kucherawy wrote: Fair enough.  Does the charter need to say that a revision to best practices, relative to the replay problem, might be a possible output?  It's within the realm of possibility that no protocol work comes out of this, but a "checkpoint" about

Re: [Ietf-dkim] Rechartering

On 12/7/2022 4:26 PM, Murray S. Kucherawy wrote: Fair enough.  Does the charter need to say that a revision to best practices, relative to the replay problem, might be a possible output?  It's within the realm of possibility that no protocol work comes out of this, but a "checkpoint" about

Re: [Ietf-dkim] Rechartering

On December 8, 2022 12:26:45 AM UTC, "Murray S. Kucherawy" wrote: >On Wed, Dec 7, 2022 at 2:06 PM Dave Crocker wrote: > >> As appealing as the AS concept is, I've never been clear how operationally >> useful they are. >> >> More to the current point, if the anti-replay work to be done

Re: [Ietf-dkim] Rechartering

On Wed, Dec 7, 2022 at 2:06 PM Dave Crocker wrote: > As appealing as the AS concept is, I've never been clear how operationally > useful they are. > > More to the current point, if the anti-replay work to be done benefits > from a position on transit vs. non-transit, then including it directly

Re: [Ietf-dkim] Rechartering

On 12/7/2022 1:47 PM, Murray S. Kucherawy wrote: Yes, it's definitely true that the standard was written from the perspective of delivery-time evaluation, and then sending that result to MUAs rather than having MUAs actually do the evaluation.  So although 4686 says that's a design goal, 6376

Re: [Ietf-dkim] Rechartering

On 12/7/22 1:47 PM, Murray S. Kucherawy wrote: Yes, it's definitely true that the standard was written from the perspective of delivery-time evaluation, and then sending that result to MUAs rather than having MUAs actually do the evaluation.  So although 4686 says that's a design goal,

Re: [Ietf-dkim] Rechartering

On Tue, Dec 6, 2022 at 4:20 PM Dave Crocker wrote: > DKIM was developed to facilitate delivery handling decisions. The > language in the RFC 4871 and RFC 6376 doesn't make this as explicit as I'd > wish, given the perspective I'm advocating, but it's got some implicating > language. References

Re: [Ietf-dkim] Rechartering

On 12/4/2022 7:52 PM, Murray S. Kucherawy wrote: On Sat, Dec 3, 2022 at 12:20 PM Jon Callas wrote: > On Dec 3, 2022, at 11:42, Dave Crocker wrote: > On 12/3/2022 11:35 AM, Jon Callas wrote: >> Agreed, and we need some other weasel word than "lightweight" because there are lots

Re: [Ietf-dkim] Rechartering

On Sat, Dec 3, 2022 at 12:20 PM Jon Callas wrote: > > On Dec 3, 2022, at 11:42, Dave Crocker wrote: > > > > On 12/3/2022 11:35 AM, Jon Callas wrote: > >> Agreed, and we need some other weasel word than "lightweight" because > there are lots of people working on "lightweight" symmetric ciphers.

Re: [Ietf-dkim] Rechartering

On Saturday, December 3, 2022 2:35:55 PM EST Jon Callas wrote: > > On Dec 3, 2022, at 11:01, Stephen Farrell > > wrote: > > > > One nit though, that you should feel free to ignore if it > > was discussed already - the phrase "in a secure way" doesn't > > quite capture what the DKIM WG was trying

Re: [Ietf-dkim] Rechartering

> On Dec 3, 2022, at 11:42, Dave Crocker wrote: > > On 12/3/2022 11:35 AM, Jon Callas wrote: >> Agreed, and we need some other weasel word than "lightweight" because there >> are lots of people working on "lightweight" symmetric ciphers. Something >> like "appropriate"? >> >> Y'all know

Re: [Ietf-dkim] Rechartering

On 12/3/2022 11:35 AM, Jon Callas wrote: Agreed, and we need some other weasel word than "lightweight" because there are lots of people working on "lightweight" symmetric ciphers. Something like "appropriate"? Y'all know this is one of the many bees in my bonnet -- DKIM doesn't need a

Re: [Ietf-dkim] Rechartering

> On Dec 3, 2022, at 11:01, Stephen Farrell wrote: > > One nit though, that you should feel free to ignore if it > was discussed already - the phrase "in a secure way" doesn't > quite capture what the DKIM WG was trying to produce, e.g. > we consider unsigned DNS fine for DKIM public keys,

Re: [Ietf-dkim] Rechartering

Hiya, On 03/12/2022 06:38, Murray S. Kucherawy wrote: I've placed what I believe is the text that is closest to consensus in the datatracker: https://datatracker.ietf.org/doc/charter-ietf-dkim/ Please provide comments or criticism soon. Once it appears to be stable relative to this

Re: [Ietf-dkim] Rechartering

On 12/2/2022 10:38 PM, Murray S. Kucherawy wrote: I've placed what I believe is the text that is closest to consensus in the datatracker: +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim

Re: [Ietf-dkim] Rechartering

> On 3 Dec 2022, at 06:38, Murray S. Kucherawy wrote: > > I've placed what I believe is the text that is closest to consensus in the > datatracker: > > https://datatracker.ietf.org/doc/charter-ietf-dkim/ > > > Please provide comments or

Re: [Ietf-dkim] Rechartering

On Saturday, December 3, 2022 5:33:27 AM EST Alessandro Vesely wrote: > On Sat 03/Dec/2022 07:38:24 +0100 Murray S. Kucherawy wrote: > > I've placed what I believe is the text that is closest to consensus in the > > datatracker: > > > > https://datatracker.ietf.org/doc/charter-ietf-dkim/ > > > >

Re: [Ietf-dkim] Rechartering

On Sat 03/Dec/2022 07:38:24 +0100 Murray S. Kucherawy wrote: I've placed what I believe is the text that is closest to consensus in the datatracker: https://datatracker.ietf.org/doc/charter-ietf-dkim/ Please provide comments or criticism soon. Please add the other Wei's I-D:

Re: [Ietf-dkim] Rechartering

I've placed what I believe is the text that is closest to consensus in the datatracker: https://datatracker.ietf.org/doc/charter-ietf-dkim/ Please provide comments or criticism soon. Once it appears to be stable relative to this audience, I'll send it on its way for internal (IESG) and then

Re: [Ietf-dkim] Rechartering

I support this. If the consensus is “that specific parts of the message have not been altered” should be added I’d support that, too. laura > On 28 Nov 2022, at 02:30, Murray S. Kucherawy wrote: > > Hi folks, > > Area Director hat on here: > > The discussion Barry kicked off has been

Re: [Ietf-dkim] Rechartering

On 11/28/2022 12:14 AM, Murray S. Kucherawy wrote: On Sun, Nov 27, 2022 at 6:50 PM Dave Crocker wrote: This does not provide any real understanding of how replay is accomplished.  And since it's easy to explain and doesn't take much text, I'll again encourage including that in the

Re: [Ietf-dkim] Rechartering

On November 28, 2022 8:17:21 AM UTC, "Murray S. Kucherawy" wrote: >On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman >wrote: > >> I would add mention of the problem statement draft. I think it may turn >> out >> to be the most important of the ones we have now. >> > >Do you mean: Mention it

Re: [Ietf-dkim] Rechartering

On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman wrote: > I would add mention of the problem statement draft. I think it may turn > out > to be the most important of the ones we have now. > Do you mean: Mention it as a mandatory deliverable? Should we still produce that document even if we

Re: [Ietf-dkim] Rechartering

On Sun, Nov 27, 2022 at 6:50 PM Dave Crocker wrote: > On 11/27/2022 6:30 PM, Murray S. Kucherawy wrote: > > Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for > > using a digital signature to associate a domain identity with an email > > message in a secure way, and to assure

Re: [Ietf-dkim] Rechartering

On November 28, 2022 7:22:33 AM UTC, Wei Chuang wrote: >On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman >wrote: > >> On Sunday, November 27, 2022 9:30:49 PM EST Murray S. Kucherawy wrote: >> > Hi folks, >> > >> > Area Director hat on here: >> > >> > The discussion Barry kicked off has been

Re: [Ietf-dkim] Rechartering

On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman wrote: > On Sunday, November 27, 2022 9:30:49 PM EST Murray S. Kucherawy wrote: > > Hi folks, > > > > Area Director hat on here: > > > > The discussion Barry kicked off has been interesting, but it has strayed > > (and mea culpa, in part, because

Re: [Ietf-dkim] Rechartering

On Sunday, November 27, 2022 9:30:49 PM EST Murray S. Kucherawy wrote: > Hi folks, > > Area Director hat on here: > > The discussion Barry kicked off has been interesting, but it has strayed > (and mea culpa, in part, because the material is interesting) from the work > of discussing a charter.

Re: [Ietf-dkim] Rechartering

On 11/27/2022 6:30 PM, Murray S. Kucherawy wrote: Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for using a digital signature to associate a domain identity with an email message in a secure way, and to assure receiving domains that the message has not been altered since the