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

[Douglas Otis]

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