Re: [Ietf-dkim] Rechartering

[Wei Chuang <[e-mail]>]

On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman <[e-mail]>
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 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.


+1 (granted my partiality).  Hopefully it can provide helpful context and
framing device.


> 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".
>
>
On this I'm more with the MSK version, that we ought to create a
specification.  To me at least, the problem with DKIM replay is that it is
indistinguishable to a receiver from other benign forwarding flows.  I
believe the proposed drafts help us do this though different approaches.

-Wei