On November 28, 2022 7:22:33 AM UTC, Wei Chuang
<weihaw=40google....@dmarc.ietf.org> wrote:
>On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman <skl...@kitterman.com>
>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
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
