Re: [Ietf-dkim] Rechartering

[Scott Kitterman <[e-mail]>]

On November 28, 2022 7:22:33 AM UTC, Wei Chuang <weihaw=[e-mail]> wrote:
>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.

My proposal doesn't preclude that.  I'm not convinced that the problem is reasonably solvable and a new specification may not be appropriate.  Let's not assume we know more than we do at this point.

I am, however, more worried about the compatibility language, so I could live with that.

Scott K