Re: [ietf-dkim] draft-allman-dkim-{base,ssp}-01.txt

Eric,

I have updated and published a version of the threat review that  
considers an alternative to the SSP mechanism.
The html and txt versions of this draft are now available at:
http://www.sonic.net/~dougotis/id/draft-otis-dkim-threats-01.html
http://www.sonic.net/~dougotis/id/draft-otis-dkim-threats-01.txt

The current SSP policy for DKIM offers two seemingly poor choices:

1) Allow "third-party" signatures where messages survive list- 
servers, e-invites, news articles, photo kiosks, greeting cards, and  
other numerous services that should adopt message signing.
2) Not allow "third-party" signatures as the only means to repudiate  
invalid uses of an email-address.
It would seem not enough consideration has been given the recipient.   
When the "third-party" exclusion is asserted, it becomes the task of  
the recipient to white-list sources that may legitimately introduce  
or reintroduce messages into the email transport system where the  
From email-address domain may differ.  The recipient is also tasked  
to deal with message replay abuse, as no adequate solution has been  
proffered.  Key revocation is not a practical solution.  How are  
these problems are to be resolved?
SSP is complex requiring parsing of several record types.  Such a  
policy mechanism can not be quickly integrated if to offer immediate  
relief from phishing attacks.  Immediate incorporation should be  
simplified to a single record query, preferably to an industry  
offered service, where any returned record then demands that all  
originating or introducing parameters and headers must be signed by  
the domain, with an exception made when the recipient is within this  
domain.  This would establish a special two-party mode of  
communication as a stronger interim fix for phishing attacks  than  
that offered by SSP assertions.
With the phishing problem handled as a special case, DKIM could  
concentrate on protecting the email channel and not the email-address  
of the author, which results in a great deal of service related  
disruption.  In lieu of attempts to offer direct protection, there  
are several opportunistic techniques that DKIM affords that better  
defends against spoofing, without needing to make separate policy  
assertions.  Importantly, basing policy upon the RFC2822 conventions  
for the header that introduced the message rather than the From, will  
allow current email services to not be disrupted, and invalid  
messages that appear to have been introduced by the domain can be  
repudiated.  All types of services should be encouraged to sign  
messages.
DKIM must consider the problems created by the millions of  
compromised systems that currently exist.  The alternative security  
threat review attempts to better cover this topic.  I also noticed  
that there is a suggestion that synthetic records may be appropriate  
in the SSP draft for some odd reason.  There should be a threat  
review made regarding how this may make DKIM more difficult to defend.
-Doug






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