Re: [Ietf-dkim] Rechartering

[Scott Kitterman <[e-mail]>]

On November 28, 2022 8:17:21 AM UTC, "Murray S. Kucherawy" <[e-mail]> wrote:
>On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman <[e-mail]>
>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 conclude replay can't be
>solved?

I had been thinking about it as an input, since that document more fully describes the problem.
>
>> I still think "compatible with DKIM's broad deployment" is too narrow.
>> Also,
>> I think it's one reasonable conclusion the group might reach is that the
>> cure
>> is worse than the disease and a resolution along the lines of "remove
>> signatures during delivery" and "be more careful about what you sign
>> because
>> signing bad things will hurt your domain's reputation" may be the most
>> appropriate approach.
>>
>
>Yes, I think it's always implied that a working group can throw in the
>towel if consensus is to do that.  I've never seen it spelled out in a
>charter that this is an available option, but we can make it explicit if
>people feel doing so would help set the scope.

As long as there's a consensus in the group for a solution, even if it's not new protocol, I don't think that's giving up.  If we quit because we can't reach rough consensus on a way forward, I think that could reasonably be characterized as throwing in the towel.
>
>> How about instead of "The DKIM working group will produce one or more
>> technical specifications that describe the abuse and propose
>> replay-resistant
>> mechanisms that are compatible with DKIM's broad deployment" we say "The
>> DKIM
>> working group will evaluate potential mechanisms to mitigate this attack
>> and
>> produce one or more technical specifications that describe the abuse and
>> propose improvements which, consistent with compatibility with DKIM's
>> broad
>> deployment and general email protocols, will reduce the impact of replay
>> attacks".
>>
>
>I think those say approximately the same thing, so I'm fine with either.
>
I agree it's not a large difference, but I'd prefer to be more explicit about general email compatibility.

Thanks,

Scott K