Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does no

On Aug 18, 2005, at 8:59 AM, Jim Fenton wrote:

> Earl Hood wrote:
>
> > On August 17, 2005 at 22:07, Jim Fenton wrote:
> >
> > > > When a DKIM verifier, "V", receives the message, the signature
> > > > validates cryptographically (remember, the signer public key is
> > > > retrieved from EXAMPLE.com).  The verifier now checks the OA SSP by
> > > > query example.org's nameserver.  The query returns no record  
> > > > available.
> > > > What verification status should V return?
> > > V should say that the message is signed by a third party.
> > I think this is dangerous behavior.
> >
> > What value is there to the recipient stating that the the message was
> > signed by a third-party.  DKIM should not facilitate spoofing, and
> > the example I gave, spoofing is the intent.  There is a danger that
> > giving _any_ positive verification of the signature can legitimize
> > the message in the recipient's mind.
> A third-party signature is a lot weaker assertion than an OA  
> signature, unless you know something about the third party.
The risk would be related to how this assertion is perceived by the  
recipient.  If all they see is a highlight or a DKIM verification  
icon, then it would be difficult to discern third-party from OA.  In  
the general case, there would be nothing seen.  By the way, is the OA  
algorithm still being considered?  There was some talk about making  
this only the From rather than tossing it to the Sender when there  
are multiple From addresses.  A concept I am sure will confuse many  
recipients as well.
> > If no SSP record is defined, "never signs" should be assumed (note
> > the current SSP draft does support a "never signs" policy).  This  
> > will
> > prevent malicious domains from exploiting any "trust" DKIM generates
> > in order to spoof identities.
> Actually, the current SSP draft supports a "never sends email"  
> policy, which is quite different.
This concern is related to a goal of ferreting out obviously spoofed  
messages for the naive user, based upon domain-wide assertions.  By  
dropping this goal presently, these issues become immaterial.  This  
is a very difficult goal to achieve due to many tactics that remain  
available to dodge protections attempted by the various possible  
algorithms. (a long row to hoe.)
DKIM could take the view that simply making the "accountable domain"  
visible by the MUA will eventually deal effectively with this naive  
user issue.  Until this information is displayed, the "other" goals  
of DKIM are being met.  In other words, no additional icons or  
notations should be added without displaying the "accountable domain".
The "accountable domain" still provides an effective means for basing  
acceptance.  Some header insensitive techniques could permit  
rejection of messages that fail to meet demanded criteria and would  
be easier to defend.
Domain-wide assertions-
 (Assume header insensitive as this does _not_ consider what the  
naive user sees.)
 (Also assumes a signature flag that limits the addition of Sender &  
Resent-*.)
1- Employs DKIM
2- Employs DKIM universally
3- Allows TP signing
4- Allows sub-domain TP signing
5- Disallows all TP signing
6- Never sends email

It would seem counter productive to for assertion 5 to be the default  
taken as this would greatly discourage larger ISP from universally  
signing all outbound mail.  For those where this would matter, then  
making the assertion should be required.
> > Someone at example.org may not know what EXAMPLE.com does, so
> > they should not be adversely affected by the application of DKIM
> > by EXAMPLE.com.
> Exactly.  Are you suggesting that the default should be:
> (1) Treat any signature from the OA (example.org) with suspicion, or
> (2) Treat any signature on a message from the OA with suspicion ?
>
> If it's (2), it means that domains that haven't deployed DKIM that  
> send through mailing lists to domains that are checking SSP would  
> have those messages marked as suspicious.

Here the trade-off is rather clear.  The restrictions on TP  
signatures is related to combating phishing exploits which affect  
only a minority of domains.  The majority of domains should be  
willing to allow their messages to be "spoofed" (third-party  
signatures) out of sheer convenience.
> I don't have nearly as much trouble with (1), but it only helps  
> with marking messages with invalid signatures as suspicious  
> (presumably attackers can't attach valid signatures).  But if a  
> domain is checking SSP, wouldn't they be checking the signature as  
> well?
What does suspicious mean to the recipient in this case?


> > Also, DKIM does not support the benevolent scenario you mention
> > very well.  Since the validity of a signature is determined by the
> > OA's SSP, a mailing list cannot add a signature if the SSP forbids
> > third-party signing (which may be common for security reasons).
> It depends on how one interprets a message, given an EXCLUSIVE SSP,  
> with a third-party signature as compared with a message with no  
> third-party signature (and presumably no valid OA signature in  
> either case).  One way to look at this is to let the mailing list  
> sign everything, but then the verifier just ignores the out-of- 
> policy third-party signature.  Another way is to require the  
> mailing list to consult SSP, and sign only those messages that  
> permit third party signatures, and for the verifier to treat  
> messages with out-of-policy signatures more harshly than those that  
> don't.  I favor the former approach, because it makes things  
> simpler for mailing lists (why check SSP at every step?) and  
> because it puts the decision in the hands of the recipient's  
> verifier because it's really the recipient we're serving.
Another view would be for the mailing-list to leave all signed  
messages intact.  There would then be no added overhead groping for  
SSPs.  The mailing-list may adopt a convention where new headers  
replace the technique of message modification.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org