Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote: > I agree with this and have been working to recruit folks to come here. I’ll > also be in Brooklyn and pitching the need for participation in the IETF > working group from folks in the email space who are seeing issues with this. I'll be

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 8/4/23 2:29 PM, Murray S. Kucherawy wrote: Colleagues, On Fri, Aug 4, 2023 at 12:08 PM Michael Thomas wrote: Exactly. Any proposed modifications to DKIM should be based on DKIM itself. Anything else is off-topic. It's not like you can't propose the ARC modifications to

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

Colleagues, On Fri, Aug 4, 2023 at 12:08 PM Michael Thomas wrote: > Exactly. Any proposed modifications to DKIM should be based on DKIM > itself. Anything else is off-topic. It's not like you can't propose the > ARC modifications to DKIM in terms of DKIM itself, though all of those >

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 8/4/2023 12:03 PM, Jim Fenton wrote: The charter calls for a standards-track specification by December. It would seem problematic if it has a normative reference to an experimental specification. ahh.  thanks for clarifying. any number of things might resolve that, but yes, it's good to

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 8/4/23 12:03 PM, Jim Fenton wrote: The charter calls for a standards-track specification by December. It would seem problematic if it has a normative reference to an experimental specification. But a call for adoption has not been issued yet, so perhaps this is jumping the gun.

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 8/4/2023 11:57 AM, Jim Fenton wrote: On 4 Aug 2023, at 11:53, Dave Crocker wrote: On 8/4/2023 11:39 AM, Jim Fenton wrote: I’m even less clear on draft-chuang-mailing-list-modifications. Does it have to do with the currently chartered work ... it will help to hear specifics, rather than

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 4 Aug 2023, at 11:57, Dave Crocker wrote: > On 8/4/2023 11:51 AM, Jim Fenton wrote: >> I was referring to draft-chuang-replay-resistant-arc-07, not what is >> mentioned in the subject line. It refers to RFC 8617 which is experimental, >> although it lists it as an informative rather than a

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

That is, to the extent that you disagree about its relevance, it will help to hear specifics, rather than your asking a generic question that throws a burden of proof back on the document author, without providing them any indication what criteria you are applying here or any detail about

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 4 Aug 2023, at 11:53, Dave Crocker wrote: > On 8/4/2023 11:39 AM, Jim Fenton wrote: >> I’m even less clear on draft-chuang-mailing-list-modifications. Does it have >> to do with the currently chartered work > > > DKIM WG charter: > >"it will produce one or more technical specifications

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 8/4/2023 11:51 AM, Jim Fenton wrote: I was referring to draft-chuang-replay-resistant-arc-07, not what is mentioned in the subject line. It refers to RFC 8617 which is experimental, although it lists it as an informative rather than a normative reference which I think is incorrect. You

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 8/4/2023 11:39 AM, Jim Fenton wrote: I’m even less clear on draft-chuang-mailing-list-modifications. Does it have to do with the currently chartered work DKIM WG charter: "it will produce one or more technical specifications that propose replay-resistant mechanisms." I don't have

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 4 Aug 2023, at 11:43, Dave Crocker wrote: > On 8/4/2023 11:39 AM, Jim Fenton wrote: >> concerns about creating a dependency on something experimental > > > I missed the details about a 'dependency'. > > What is it that would be dependent and what is it it would be dependent on? I was

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 8/4/2023 11:39 AM, Jim Fenton wrote: concerns about creating a dependency on something experimental I missed the details about a 'dependency'. What is it that would be dependent and what is it it would be dependent on? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 8/4/23 11:31 AM, Tim Wicinski wrote: Michael Actually it appears draft-chuang-replay-resistant-arc is listed in the charter (I had to check for myself). We can have the larger ARC discussion but I'll want to talk to Murray and Laura on that also. And what of the mailing list traversal?

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 4 Aug 2023, at 11:31, Tim Wicinski wrote: > Michael > > Actually it appears draft-chuang-replay-resistant-arc is listed in the > charter (I had to check for myself). > We can have the larger ARC discussion but I'll want to talk to Murray and > Laura on that also. Agree with Mike’s concerns

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

Michael Actually it appears draft-chuang-replay-resistant-arc is listed in the charter (I had to check for myself). We can have the larger ARC discussion but I'll want to talk to Murray and Laura on that also. tim On Fri, Aug 4, 2023 at 2:27 PM Michael Thomas wrote: > > On 8/4/23 11:12 AM,

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 8/4/23 11:12 AM, Wei Chuang wrote: Hi all, I just wanted to mention two proposals for tolerating mailing list modifications as suggested in person IETF-117. They both use ARC headers as infrastructure, but go about tolerating mailing list modifications in different ways. 1) Disclose and

[Ietf-dkim] Updated Replay Resistant ARC draft -07

Hi all, I've updated the I-D draft-chuang-replay-resistant-arc to -07. That change does the following: * Move the SeRCi and Relay ID proposals to the appendix * Change all the examples use DARA * Clean up the text now

[Ietf-dkim] Proposals for tolerating mailing list modifications

Hi all, I just wanted to mention two proposals for tolerating mailing list modifications as suggested in person IETF-117. They both use ARC headers as infrastructure, but go about tolerating mailing list modifications in different ways. 1) Disclose and reverse mailing list transforms so that we