Still at two approaches...
http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-02.txt
http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-02.txt
DomainKeys includes a reference to:
http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-02.txt
The value of such a header is that it carries results from the bordering
MTA to other servers within the same administrative domain. This
proposed header includes terminology derived from Sender-ID, such as
pass, neutral, softfail, fail, temperror, or permerror. Definitions
given these categories have similar generalizations and should be done
with a different set of terms to avoid confusion with SPF/Sender-ID.
This header also tends to conflate every validation into being called
"authentication", where in the case of SPF/Sender-ID, these results are
"server authorization" which represents a significantly different
assurance. This terminology is dangerous, as it could mislead users
specifically due to this poor choice of terminology, header names, and
test descriptions. One option could be to clarify the action into
separate parameters, or to rename the header validation-header or
something less misleading.
Rather than depending upon path restrictions to protect this type of
header, it would be more dependable to have a MUST remove this header
prior to resending the message. Any message coming into an Internet
facing MTA with this header from an untrusted machine SHOULD be refused
when detecting an attempt to forge this header.
Call this header a validation-header to ensure it does not become
misleading when used to verify server authorizations rather than
performing name authentications, as with hosts or signatures.
The DomainKeys draft leaves open the choice of domain-wide policy
assertions and fails to consider strategies for DoS and replay attacks.
These issues could be readily resolved by including a
revocation-identifier used in conjunction with CSV as described in:
http://www.ietf.org/internet-drafts/draft-otis-mass-reputation-01.txt
IIM could utilize the same CSV approach rather than attempting to use a
wildcard TXT record for this feature. Wildcards are problematic for
this use, and even SPF no longer recommends their use in this manner.
There has been no attempt to constrain the number of keys that a domain
could theoretically publish. While allowing for a great deal of
flexibility, it also allows what could result in excessive use of this
feature.
If including the 'g=' extension within the public key, perhaps there
should be some restrictions on the use of this key type. With a Sender
header this key type would represent a validation failure. (IIM has the
same issue.) This would effectively limit the localpart of such a
signature to always be visible. It would also mean it could not be used
to sign mail appearing to be from other domains or localparts. This
restriction would preserve anti-phishing properties without specialized
MUAs.
Perhaps there should also be some recommended limit on the number of
such key types. Have there been any estimates made resulting from a
prevalence of a per-user key distribution using DNS?
Both DomainKeys and Identified Internet Mail express a desire to retain
user signed keys that occupy the same domain as MTA signed keys.
Obviously there is less risk associated with MTA signed keys becoming
abusive. With DomainKeys, without the granular option, the DNS burden
is limited. Identified Internet Mail requires a fingerprint of the
localpart using their KRS server to perform the same function.
IIM appears to offer greater detail pertaining to signatures, but has
not changed significantly with respect to leaving openings in the body
count, for example. An alternative for the header copies and body count
could be a simple redundancy checksum and size noted for the significant
headers and message body. Error recovery should remove any injected
information that did not appear in the originally signed message. Such
a strategy to improve signature robustness could work in the same
fashion for either DomainKeys or IIM.
While IIM appears to be more corporate centric, a design weakness of a
body count, or the need to validate fingerprints for all users when
checking localparts, seems a detriment more than a benefit in this
situation. I would imagine few corporations would be willing to add
their signature to an mail they have never seen and can not log. I
would also suspect corporations would want an ability to thwart replays
without depending upon outside reputation services. The scheme offered
in the mass-reputation review could serve this function for either
DomainKeys or IIM.
There are enough of a common foundation with common problems still left
to be resolved as documented in:
http://www.ietf.org/internet-drafts/draft-housley-mass-sec-review-00.txt
These can be joined together to form a common solution. What are the
sticking points?
I could describe these differences and outstanding issues. Perhaps
there could be consensus found in a process of defining outstanding
problems and common goals. I want to see an email domain signature
method succeed, as it offers the greatest consumer protections compared
to an alternative path registration scheme. I would like to see this
move forward within the IETF to ensure the technical aspects are well
covered. After all, this will impact a vital application. I am
optimistic inputs from those in both camps, as well as experts
participating within IETF will be beneficial, when there are clear
goals. (I would not consider myself an expert.) At least both camps
want to see the results freely used.
-Doug