On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman <[email protected]> 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
