[ietf-dkim] DKIM Agenda Item Safer than SSP

[Douglas Otis]

As indicated in the threat draft, SSP will not mitigate both a likely  
and high impact threat caused by a lack of email-address recognition  
due to internationalization.

One possible approach for handling this issue would be to utilize  
known correspondence lists (perhaps obtained from the address book or  
selected correspondents) in conjunction with message annotation.   
Message annotation of known and verified sources is a proactive  
recommendation of the APWG.  Additional protection can be achieved by  
leveraging a known list with advice from the signing domain.

See:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-reliance-level-00.txt

Messages annotated based upon known signing domains conflicts with  
generalized SSP repudiation assertions that "all messages from a  
particular email-address domain are signed."  This conflict between  
annotation and SSP repudiation induces a significant risk when  
sources within the signing domain are not equally vetted.   
Partitioning message sources within known signing domains permits  
safe retention of message repudiation, while not inadvertently  
causing recipients to trust sources beyond what the signing domain  
considers prudent.  Offering accurate reliance advice helps the  
signing domain retain favorable annotations for their well-vetted  
message sources.

One possible alternative for the reliance level could be conventions  
for selector labels, but this approach will cause a greater impact  
upon the DNS message size and cache requirements.  The example  
reliance level draft offers three separate domain partitions.  Each  
source partition could easily be separately assigned an accrual  
status within a single query.  A diversity of selector label names  
for achieving the segregation of sources increases the amount of  
information that must be distributed out-of-band.

Rather than focusing upon SSP, another concern is related to DoS  
attacks.  These attacks might be mitigated by using name-path  
registration.  The name-path as defined can indicate whether the path  
is open or closed ended to allow repudiation of unsigned messages,  
while also providing a safe method to defend against DoS.

See:
http://www.ietf.org/internet-drafts/draft-otis-smtp-name-path-00.txt

-Doug