ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Should DKIM drop SSP?

2005-10-27 13:51:19

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- address.

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 acquired.

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. : )


-Doug



_______________________________________________
ietf-dkim mailing list
http://dkim.org