[ietf-dkim] Re: Should DKIM drop SSP?
dotis at mail-abuse.org
Thu Oct 27 13:45:20 PDT 2005
On Oct 26, 2005, at 7:04 PM, Frank Ellermann wrote:
> Douglas Otis wrote:
>> Can you acknowledge the trade-off and defend this choice?
> I'm more interested in your choice, DKIM without SSP. Your
> vision is some kind of reputation system, e.g. you know that
> NNNNN are good guys.
DKIM signatures will be invalid for many reasons for perhaps a long
deployment period. A reputation system can be based upon the signer
only when the signature remains valid. Otherwise, use of the remote
IP address, or perhaps a verified EHLO would be used.
> Therefore you want to accept anything
> that's really from NNNNN. If it comes directy from one of
> their mailouts you don't need DKIM, that situation is faster
> handled by one of the HELO-checking protocols like CSV or SPF.
With the assured maximum of 1 lookup, CSV could offer DoS protections
within the same name space as the signer. The signer however offers
a significant advantage when attempting to remedy abuse.
> So your focus are "redirected" mails. Wild and wonderful 251-
> forwarding from who knows. A DKIM signature _should_ survive
> this torture, and then you can check that the source was NNNNN.
The concerns regarding the SSP policy is not confined to Unix style
forwarding, but includes list-serves or e-invites that sign messages,
and cases where an ISP wishes to sign messages without introducing
Sender headers that create support issues.
> How do you catch the crap that only claims to be "from" NNNNN ?
Assuming signatures have been proven reliable, then fewer
repercussions occur regarding assertions made with respect to all
email that appears to have been "introduced" per RFC2822 by domain
NNNNN. This association for the assertion allows DKIM to directly
provide the desired repudiation of unsigned messages without
degrading the integrity of email delivery.
As repudiation is most often needed for prior correspondents, these
assertions could and should be directly carried within the message,
as this method is likely the most secure means for distributing these
few bits of information. I also assume the deployment period will
allow introduction of DKIM aware MUAs and MTA able to collect this
information. When a recipient has never seen a message from YYYYYY,
most will be more careful about believing the content of such a
message or perhaps even accepting these messages for a period of
time. Automatic collection of the binding information found within
the message could happen when the signing-domain is within email-
Use of an opaque-identifier option will quickly isolate compromised
systems by third-parties and will also allow the use of this
information to create a type of pseudo-certificate that identifies
the account used to send the message. These pseudo-certificates can
opportunistically be bound to email-addresses being used by the
account holder, which does not require any administration by the
provider to accomplish the association. (The real low cost approach.)
Within the message signature, there can be assertions made that
indicate that all messages "introduced" by the signer are signed.
There can be assertions that indicate the email-address bound to the
signature has been verified. There could be assertions that indicate
the use of an opaque-identifier will associate with the account.
Several of these assertions within messages can be safely acquired
automatically by the MTA and MUA. By using this approach, there
would not be a need to look for separately published policy
assertions or binding tips, as they would have already been securely
The opaque-identifier option would also allow the detection of intra-
domain spoofing. With the current proposal, intra-domain spoofing
can not be detected and relies upon restrictions made upon the
account holder. This limits the email-address account holders would
be allowed to use. An opaque-identifier approach would allow current
practices to remain unchanged, while offering every account holder a
pseudo-certificate <OID>.<signing-domain>. Sweet. : )
More information about the ietf-dkim