By way of explaining why I have offered an alternative draft charter...
On 11/9/2022 4:08 AM, Barry Leiba wrote:
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
The term "email authentication" is substantially broader and even
arguably different from what DKIM does. The language here seems to
reflect that confusion. The term is normally taken to mean that the
indicated authorship is validated, but DKIM does not do that.
not been altered since the signature was created. Receiving systems
DKIM's data integrity utility only applies to the portions covered by
the signature. This can be quite a small portion of the message. Hence
DKIM does not assure that the message has not been altered. And while
integrity is often cited about DKIM, that feature was not really a
design goal; so it's not surprising that it satisfies the goal erratically.
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.
This appears to be the only place that the concept of a replay is
included in the charter, and then essentially as a side-comment.
The DKIM working group is being restarted to work on this problem.
Not really relevant to the substance or use of a charter.
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.
In spite of seeming reasonable to include, these sorts of statements
turn out to have little utility and, often, little predictive power.
Arguably they can actually create some ambiguity to wg goals and conduct.
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.
drat. I should have included this in my draft text.
Unrelated changes to DKIM are out of scope for this effort.
Unrelated work is always out of scope.
The thing that deals with scoping meaningfully is careful drafting of
the text that says what is /in/ scope.
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.
These can be cited in the wg datatracker and aren't needed here, since
they are only initial input and, as you note, other input is acceptable.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@[email protected]
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
