On Aug 15, 2005, at 6:09 PM, Dave Crocker wrote:
Equally I am wondering whether it is not distracting from the core
DKIM
authentication work to emphasize this particular requirement prior to
deployment of a signing/validating mechanism.
In other words, it is starting to look as if the mechanism for
enforcing
originator/handling linkages needs separate focus from techniques for
performing authentication.
Thoughts?
There are two ways to look at DKIM goals-
1- A mechanism that provides an accountable domain for the message.
A number of features are available as a product of the accountable
domain.
a) reputation accrual
b) directed abuse reporting
c) IP address independent basis for message acceptance
2- A mechanism that is able to optionally constrain the use the From-
domain.
a) debunk spoofed messages
A natural outcome of any method that provides a strong message
identifier would be related to reputation. Whether this feature is
expressed in terms of abuse prevention or not, this will be a
principle use. As a result, there should be considerations given how
this may be abused by miscreants. This being a goal or not, when
DKIM is expressed independently from the optional domain-assertions,
it becomes difficult to distance the DKIM mechanism from this aspect
of email handling.
Once there is an accountable domain established for a message, as an
option, some want to bind the accountable domain with the From-
domain. This is not directly a product of DKIM, but rather that of a
domain-wide assertion. There are several who embrace a concept of
constraining the use of their domain name through domain-wide
assertions. This has been a common theme. There is more than one
email related application where such assertions could be applied,
which suggests this should be kept separate, as it also tends to be
expensive, at least initially.
To clarify basic elements involved in DKIM, versus expressing domain-
wide assertions, these two efforts should be independent. This would
ensure a flexible language is used to express these two highly
independent functions.
Alas, I suspect a major reason for resisting the splitting of these
efforts is that some domain owners have had bad experiences with
reputation services. Without including the domain-wide assertion,
DKIM really only supports an aspect of this dark side.
---
In changing the architecture of the mechanism, rather than just the
architecture of the documents, I like Earl Hood's suggestion of
offering a separate body-hash within the header, rather than hashing
the header and body together at once. This would assist in
diagnosing causes of a signature failure, and perhaps even
algorithmic methods of repair as an interim solution. Keith Moore
has just suggested perhaps the body should be signed by the author.
Creation of the body hash would permit a simple method for signing
the body by multiple entities, at the expense of the signature
overhead and the added key of course.
Keith Moore added an idea of "capturing" the 'RCPT TO' or some such
thing as proof of intent by the sender. This may also be a method
that could help identify possible replay attacks, and Earl has also
pointed out that feature while I was writing this message. This
would be another method to mitigate any revocation mechanism.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org