Re: [Ietf-dkim] Rechartering

I support this.

If the consensus is “that specific parts of the message have not been altered” should be added I’d support that, too. 

laura 

> On 28 Nov 2022, at 02:30, Murray S. Kucherawy <superuser@gmail.com> 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.
> _______________________________________________
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
laura@wordtothewise.com		

Email Delivery Blog: http://wordtothewise.com/blog	