From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: ietf-dkim@ietf.org
Reply-To: iesg@ietf.org
Subject: WG Review: Domain Keys Identified Mail (dkim)
A new IETF WG has been proposed in the Applications and Real-Time Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send your
comments to the IESG mailing list (iesg@ietf.org) by 2023-01-27.
Domain Keys Identified Mail (dkim)
-----------------------------------------------------------------------
Current status: Proposed WG
Chairs:
TBD
Assigned Area Director:
Murray Kucherawy <superuser@gmail.com>
Applications and Real-Time Area Directors:
Murray Kucherawy <superuser@gmail.com>
Francesca Palombini <francesca.palombini@ericsson.com>
Mailing list:
Address: ietf-dkim@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/ietf-dkim/
Archive: https://mailarchive.ietf.org/arch/browse/ietf-dkim/
Group page: https://datatracker.ietf.org/group/dkim/
Charter: https://datatracker.ietf.org/doc/charter-ietf-dkim/
Domain Keys Identified Mail (DKIM, RFC 6376) defines a method for
using a digital signature to associate a domain identity with an email
message using an appropriate cryptographic authentication mechanism, 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 additional recipients, in a
fashion that retains the original signature. With an author and a recipient
collaborating, this can "replay" the message, using the original signer's
reputation to propagate email with problematic content -- spam, phishing,
and the like.
Generally, the technical characteristics of this form of abuse match those of
legitimate mail, making its detection or prevention challenging. Timestamps
and carefully-tailored message signing conventions are appealing approaches
to replay mitigation. Each has significant limitations.
The DKIM working group will first develop a clear problem statement, which it
may choose to publish. Then, it will produce one or more technical
specifications that propose replay-resistant mechanisms. The working group
will prefer solutions compatible with DKIM's broad deployment, and there will
be an expectation that these solutions will have been through implementation
and interoperability testing before publication.
If the working group decides that is unable to identify a consensus technical
solution to this problem space, it may instead publish a report describing
the problem and summarizing the reasons that none of the proposed approaches
are acceptable.
Finally, the working group may produce documents that update operational
advice to reflect modern considerations, especially with respect to the
replay problem described above. This should be done only if there is a
consensus opinion that such advice would be based on experience rather than
theory.
Current proposals include the following drafts:
- draft-bradshaw-envelope-validation-extension-dkim
- draft-chuang-dkim-replay-problem
- 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, and may consider
or develop other proposals.
Milestones:
Apr 2023 - Post a consensus problem statement draft to the datatracker (may
not go to the IESG)
Jun 2023 - Proposal regarding plans for remaining document(s) presented to
the AD
Dec 2023 - Submit technical specifications for replay-resistant DKIM
enhancement(s) to the IESG at Proposed Standard
Dec 2023 - Submit revised operational advice for replay-resistant DKIM use
to the IESG at Informational
WG action announcement
WG Action Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>,
dkim-chairs@ietf.org,
ietf-dkim@ietf.org
Subject: WG Action: Rechartered Domain Keys Identified Mail (dkim)
The Domain Keys Identified Mail (dkim) WG in the Applications and Real-Time
Area of the IETF has been rechartered. For additional information, please
contact the Area Directors or the WG Chairs.
Domain Keys Identified Mail (dkim)
-----------------------------------------------------------------------
Current status: Proposed WG
Chairs:
Tim Wicinski <tjw.ietf@gmail.com>
Laura A <laura@wordtothewise.com>
Assigned Area Director:
Murray Kucherawy <superuser@gmail.com>
Applications and Real-Time Area Directors:
Murray Kucherawy <superuser@gmail.com>
Francesca Palombini <francesca.palombini@ericsson.com>
Mailing list:
Address: ietf-dkim@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/ietf-dkim/
Archive: https://mailarchive.ietf.org/arch/browse/ietf-dkim/
Group page: https://datatracker.ietf.org/group/dkim/
Charter: https://datatracker.ietf.org/doc/charter-ietf-dkim/
Domain Keys Identified Mail (DKIM, RFC 6376) defines a method for
using a digital signature to associate a domain identity with an email
message using an appropriate cryptographic authentication mechanism, 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 additional recipients, in a
fashion that retains the original signature. With an author and a recipient
collaborating, this can "replay" the message, using the original signer's
reputation to propagate email with problematic content -- spam, phishing,
and the like.
Generally, the technical characteristics of this form of abuse match those of
legitimate mail, making its detection or prevention challenging. Timestamps
and carefully-tailored message signing conventions are appealing approaches
to replay mitigation. Each has significant limitations.
The DKIM working group will first develop and publish a clear problem
statement. Then, it will produce one or more technical specifications that
propose replay-resistant mechanisms. The working group will prefer solutions
compatible with DKIM's broad deployment, and there will be an expectation
that these solutions will have been through implementation and
interoperability testing before publication.
If the working group decides that is unable to identify a consensus technical
solution to this problem space, it may instead publish a report describing
the problem and summarizing the reasons that none of the proposed approaches
are acceptable.
Finally, the working group may produce documents that update operational
advice to reflect modern considerations, especially with respect to the
replay problem described above. This should be done only if there is a
consensus opinion that such advice would be based on experience rather than
theory.
Current proposals include the following drafts:
- draft-bradshaw-envelope-validation-extension-dkim
- draft-chuang-dkim-replay-problem
- 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, and may consider
or develop other proposals.
Milestones:
Apr 2023 - Post a consensus problem statement draft to the datatracker (may
not go to the IESG)
Jun 2023 - Proposal regarding plans for remaining document(s) presented to
the AD
Dec 2023 - Submit technical specifications for replay-resistant DKIM
enhancement(s) to the IESG at Proposed Standard
Dec 2023 - Submit revised operational advice for replay-resistant DKIM use
to the IESG at Informational