Re: [Ietf-dkim] Rechartering

[Scott Kitterman <[e-mail]>]

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.
> 
> I've set the stage for re-chartering in the system, and now we need some
> charter text.  Dave and Barry submitted text, which I've synthesized into
> what's below.  Let's keep this thread just to discussion the charter text;
> if you want to continue to debate the technical solutions or problem space,
> please start other threads or reply to the other existing ones.
> 
> Here's my run at a charter; please provide suggestions or comments, or tell
> us if you think it's ready to go.  It's a variant of Barry's version with
> parts of Dave's merged in.  I've kept the list of candidate documents as a
> starting point; the WG doesn't actually have to use any of them if that's
> where consensus lands.
> 
> But let's figure out consensus on a charter before we try to hammer out
> consensus on solutions.
> 
> -MSK
> 
> --
> 
> 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 signature was created.  Receiving systems
> can use this information as part of their message-handling decision.
> This can help reduce spam, phishing, and other unwanted or malicious
> email.
> 
> A DKIM-signed message can be re-posted, to a different set of recipients,
> without
> disturbing the signature's validity.  This can be used to confound the
> engines that
> identify abusive content.  RFC 6376 identified a risk of these "replay"
> attacks, but
> at the time did not consider this to be a problem in need of a solution.
> Recently,
> the community has decided that it has become enough of a problem to warrant
> being revisited.
> 
> 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.  The working group may produce documents
> describing
> relevant experimental trials first.
> 
> Current proposals include the following drafts:
> 
>  - draft-bradshaw-envelope-validation-extension-dkim
>  - draft-chuang-replay-resistant-arc
>  - draft-gondwana-email-mailpath
>  - draft-kucherawy-dkim-anti-replay
> 
> The working group may adopt or ignore these as it sees fit.

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.  

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.

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

Scott K