On August 29, 2005 at 13:18, Dave Crocker wrote:
Lead-in problem statement:
,---
| Forgery of headers that indicate message origin is a problem for
users of
| Internet mail.
'---
DKIM is an authentication technique. It authenticate an identity.
What kind of identity? There are multiple entities and roles involved
with the creation, transmission, and reception of an email message.
Authentication is not needed, unless one is worried about invalid uses of
identities. I think that it is reasonable to call that "forgery".
Not sure. Many have stated that DKIM identifies an "accountable"
domain. In this case, forgery with respect to an email message
is not really addressed.
Forgery cannot be addressed unless the specific role an identity plays
in the transmission of a message is clearly specified. For example,
saying you are "accountable" is different than saying your are
the "originating domain." The latter directly implies the type
accountability the identity is asserting while the former does not.
Saying you are a "forwarding domain" directly implies the type of
accountability the identity is asserting. Etc, etc.
DKIM, as it is currently defined, supports two general roles:
(1) First-party: Which is not directly defined in the drafts, but
has been mentioned on ietf-mailsig and ietf-dkim. First-party is
supposed to indicate some form of direct relationship with the
originator of the message.
(2) Third-party: Mentioned in the drafts, any entity not have a direct
relationship with the message originator.
Are these two basic identifying roles sufficient to address (part of)
the forgery problem?
If I am not mistaken, Doug's main problem is the technical difficulting
in binding a first-party signer with the message originator.
I too am looking forward to Doug's draft revision since parsing his
verbose posts can be challenging for a sleep-deprived person :)
The goal of DKIM.
,---
| The DKIM working group will produce standards-track specifications that
| permit authentication of message headers during transit, using
public-key
| signatures and based on domain name identifiers.
'---
While one could describe signature verification as authenticating the
signature header, this is not addressing the problem statement.
Ensuring that the received headers are the headers that were sent does not
address the problem of forgery?
No. Received headers just deal with transmission, so a signature
on that denotes that a message passed through a given entity, but it
does not address the message contents and asserts any validation on
identities claimed in the message (e.g. originating fields).
To make that assertion, the role of the signer must be known and the
signer's relationship to the identities it is asserting.
The fact that DKIM provides a digital signature based on a hash of the messag
e
headers means that, in fact, it is ensuring that any modification to the
headers, after the message is sent, will be detected. Hence, they are
authenticated... With respect to the identity doing the signing.
The message is authenticated with respect to when the message
was signed. Without knowing the role of the signer, the value of
identifying the signer is unknown.
DKIM-SSP attempts to directly addresses forgery, and those interested
in anti-forgery mechanisms advocate that the SSP component of DKIM
is critical. SSP could be useful in the anti-forgery effort, but it
needs some work.
--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org