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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html