Murray is looking at re-opening the DKIM working group, chartering it to work on replay mitigation.
To that end, I've knocked out a draft charter, which I passed by Murray (he was sitting next to me when I wrote it): he thinks it looks good. I'm posting it here for comment before Murray puts it into the datatracker to start the chartering process. To be clear: the plan is to re-open the DKIM working group with this new charter -- not to come up with a new name for a brand-new working group. And we will keep using this list, ietf-dkim@ietf.org, for discussion. Barry --------------------------------------------------------- DKIM Working Group Charter 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 – a process that has become known as “email authentication” – 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. The DKIM-Signature header field can include an “x=” tag that defines an expiration timestamp for the signature, and that tag was intended to reduce the opportunity to obtain a signed spam message and then “replay” it by simply re-introducing it to the e-mail flow. But legitimate delays involved in email submission, transmission, and delivery prevent sufficiently short expiration periods to effectively prevent such DKIM replay attacks, and other mechanisms are needed. The DKIM working group is being restarted to work on this problem. The working group will produce one or more specifications of replay-prevention or replay-mitigation mechanisms. It is expected that the working group will settle on a single Standards-Track mechanism, and that is the preferred path, but it might decide that differing proposals need Experimental trials first. Because of DKIM’s broad deployment, compatibility with existing deployments will be a critical factor, and it is unlikely that proposals that lack compatibility will proceed to publication. Unrelated changes to DKIM are out of scope for this effort. 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 will start by considering those proposals; other proposals remain welcome. --------------------------------------------------------- _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
