DKIM is an authentication technique. It authenticate an identity.
While that is a true statement, this new identity is independent of
headers normally considered to be related to forgery. Falsifying the
originator (author) of the message has nothing to do with the validity
of a DKIM signature.
"normally considered to be related to forgery".
1. If the signer chooses to include those headers into the hash, then DKIM
provides a degree of protection against their being forged after signing.
2. You appear to be focusing on a particular kind of forgery exclusively, namely
the unauthorized use of rfc2822.From addresses by the entity doing the signing.
Since the DKIM base does not attempt to protect against it, there is no
surprise (or problem) that it does not protect against it. The protection
against such forgery is a delightful and productive goal, but it is not one
attempted in DKIM base.
3. DKIM SSP provides certain protections against rfc2822.From forgery, along the
lines of what you appear to be concerned about, but again, the attempted
protection is extremely constrained, so there is no surprise that it does not do
more.
All of this seems to suggest that you are concerned that DKIM is "failing" to
perform a task that it has not set out to perform. This, in turn, suggests that
you want to pursue a different activity.
Authentication is not needed, unless one is worried about invalid
uses of identities. I think that it is reasonable to call that
"forgery".
Adding an unseen identity within a message, and being able to verify
this unseen identity, does not directly deal with the current forgery
problem.
"unseen identity"? I gather you mean that it is not guaranteed to be presented
to the recipient end-user. Indeed, presentation of validation information to
the recipient end-user is not a goal of DKIM, so it is not a surprise that it
does not do it.
"The current forgery problem". Forgive me, but I am under the impression that
there is an array of forgery problems. Which one(s) do you mean and what is the
basis for believing that DKIM is attempting to solve it(them)?
DKIM allows the inclusion of a signature. The validity of the
signature makes no statement beyond having accepted and subsequently
transmitted the message. DKIM may offer no assurances related to any
message content beyond the signature.
I was under the impression that SSP attempts more than that.
Ensuring that the received headers are the headers that were sent
does not address the problem of forgery?
The signature simply indicates this was the message sent. It makes no
claims regarding any other content.
You might want to review the nature of data integrity protection afforded by
signing a hash of the message.
Perhaps some signers confirm
content in some manner, but this does not provide the recipient any
means for concluding headers indicating the originator are valid.
So it is probably a good thing that the DKIM base does not claim that it does.
The fact that DKIM provides a digital signature based on a hash of
the message 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.
...
While indeed the signature may encompass headers and body
content, this makes no assurance any content is valid, or that any
content is being assured by the signing domain.
1. "Valid" is a rather broad concept. Are you suggesting that some sort of
alternative signing would mean that my sending you a note, with such a
signature, will contain a "valid" promise to send you money?
2. DKIM specifies what it validates with respect to the content. That is all
any specification can reasonably do. It appears that your concern is that DKIM
does not perform some other sorts of validations, which in fact it does not
claim to do.
- Establish accountable domain-specific opaque identifier.
what does domain-specific "opaque" identifier mean? Opaque to who?
Compared to what? >
The only practical solution I see for addressing replay-abuse issues
and to support effective techniques that detect forgery would be for
the signing domain to add their own opaque identifier with the
signature that is either sequential or related to the access account.
Unlike a mailbox-address, this opaque identifier could be assumed
unique for the the signing domain. The term opaque means that the
interpretation of this identifier is only understood by the signing
domain.
The opaque identifier should provide the requisite anonymity (as
opposed to the i=). An opaque identifier would still permit a high
granularity well beyond a mailbox-domain. It should be obvious
mailbox-domain authorization is limited to the granularity of the
mailbox-domain. If this domain is dereferenced, or open to third- party
signatures, then multiple domain granularity includes a much larger to
infinite set of potential miscreants. With the zombie problem being
rather prevalent, mailbox-domain(s) granularity is problematic.
Third-party restrictions are also problematic, as this will impact
normal behaviors. Opaque identifiers offer a practical solution.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org
--
d/
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
_______________________________________________
ietf-dkim mailing list
http://dkim.org