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

On Aug 18, 2005, at 1:02 PM, Earl Hood wrote:

> On August 18, 2005 at 09:57, Douglas Otis wrote:
>
> > 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.
> Why sign messages when there will be no value in doing so?

DKIM provides significant value beyond implementing a weak and  
uncertain anti-spoofing mechanism.  MUAs are not designed to ensure  
the identity of the author or sender.  As a result, MUAs often fail  
to show headers intended to indicate this information.  In addition,  
MUAs also often fail to show underlying email addresses in favor of  
"pretty names."  This makes for a poor foundation upon which to build  
any anti-spoofing mechanism without major renovations.
I would even suggest without displaying the "accountable domain,"  
DKIM results should not be exposed to the recipient simply out of  
concerns this may provide inappropriate assurances.  There is a  
hierarchy MUAs may use with respect to what gets prominently  
displayed.  Suggestions that the From takes precedence with respect  
to domain-wide assertions is based upon often false expectations this  
header is being "properly" displayed, where the information checked  
is also the information viewed.
There is concern among larger ISPs where any changes to what is being  
displayed will require an inordinate amount of support explaining  
such changes.  DKIM's greatest value is limited to actions done  
behind the scenes.  Either the message is rejected or accepted as  
perhaps the _only_ method of communication to the recipient.
If someone wishes to re-submit an email using proper and valid  
headers clearly indicating the intent of their action, should a From- 
domain administrator be able to prevent this action through a domain- 
wide assertion?  If so, this will likely cause support issues at  
other's great expense.  Already DKIM can inhibit the use of Sender  
and Resent-* headers when done by non-DKIM clients or list servers,  
even though absolutely _nothing_ dishonest is being done.
All of this havoc under the guise of an anti-spoofing mechanism?  A  
majority of recipients can still be spoofed, and there are less  
disruptive approaches.  I know I am in the minority by saying that  
anti-spoofing and anti-phishing should be considered out of scope for  
DKIM.  I know this has been used as a major selling point for DKIM  
and previously Sender-ID, but this goal is dubious and likely to fail.
There is tremendous value obtained when receiving a DKIM signed  
message.  Once an anti-replay mechanism is in place, the signing  
domain will have control over their domain name's reputation.   
Phishing can be addressed by publishing a list of compliant  
institutions that agree to certain DKIM and header practices.  Such a  
list should be offered at no cost to the recipient.  Both free and  
subscription based reputation services will become more effective at  
selectively eliminating abusers with less impact upon uninvolved  
domain owners.  Will DKIM enable safe methods facilitating the  
identification of zombie systems within larger domain?  I only hope so.
While the emphasis remains on spoofing and phishing (which DKIM can  
not really prevent), the non-disruptive and highly beneficial value  
of DKIM remains ignored.  Worse.  While ignoring these "other"  
values, simple techniques to prevent likely abuse remain ignored as  
well.

> The OA is important here, and automatically signing messages without
> explicit permission from the OA is not playing nice.

Should the re-submitter be allowed to add a Resent-* header?  What if  
they can not?  Should they then send it without even acknowledging  
who is doing the resubmission?
Your concerns narrowly relate only to a goal where DKIM is considered  
just an anti-spoofing mechanism.  Bad idea in my view.  Even when  
there is _no_ indications added at the MUA as a result of DKIM  
processing, the naive user still benefits from a system where abuse  
can be traced and handled behind the scenes.  Without impacting the  
current email architectures, DKIM allows substantial improvements to  
the way messages are processed.  The goals should place a high value  
on not disrupting how users interact with email.  Otherwise, any  
systemic disruptions will likely lead to the dropping of the DKIM  
mechanism.

> Except, if DKIM signatures were not limited to OA SSP binding, then an
> ISP could blindly sign messages, making the assertion, "this what I
> got before I sent it out."

Signatures that naturally bind to From, and others that bind to  
Resent-Sender?  Would these Resent-Sender signatures stack just like  
the Resent-Sender headers?  Would this create added susceptibilities  
with respect to DoS tactics?  You want any number of domains searched  
for domain-wide assertions, then any number of signatures checked to  
validate the entire path of the message?  Just as the last hop is  
important with respect to IP address reputations, the last signature  
should be what is important for name reputations.  Perhaps this is a  
report of abusive email.  As I said, attempts to classify what is a  
"spoof" versus what is a "normal" message should be out of scope for  
DKIM.
> For ISPs servicing multiple domains, they should only sign if the
> domain owner allows it, creating a 1st-party signing relationship
> versus a TP one.  Note, domain owner does not necessarily equal
> domain administrator.
>
> (Note, any first-party relationship will probably need to have
>  a legal basis.)
>
> IMO, from the OA perspective, enabling TP signing is bad policy from
> a security perspective.  OA will not care if other entities sign a
> message (for traceability purposes) as long as they are not claiming
> a 1st-party association.
>
> Side Note, I think it would be useful if the OA SSP allowed for
> an OA to designate a list of allowable signers.

It seems you want contracts signed before any message can be re- 
submitted.  Does this really scale or will this be overly  
disruptive?  Will email still function?  You seem to think no domains  
should permit re-submission.  Why exactly?  If all the proper headers  
are added, is this really a problem?  Should the system attempt to  
protect the naive user when there will still be methods available  
that will just as easily fool them?

> > For those where this would matter, then
> > making the assertion should be required.
> You are assuming that a domain owner is aware of DKIM.  When DKIM is
> deployed, you cannot require all domain owners to set up SSP records
> immediately.

Being able to assert universal compliance to DKIM would permit a  
means to reject messages outright when presented as a first-party  
message.  There is also a means to block headers when the message is  
not resigned.  This simply leaves blocking third-party signatures.  I  
would argue that this should be done on an exceptional basis (as in  
an industry-wide listing) and not provided as a standard DKIM  
feature.  Otherwise, should this be used widely, it will be too  
disruptive.
Eventually, the better solution would be to expose the "accountable  
domain."  Pretty name or no, this would still indicate who is being  
trusted when the message is being viewed.

> > > 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.
> There is no "willing" for domains that do not know of DKIM or have
> yet to adopt it.  DKIM must not facilitate spoofing.

This was said to illustrate how absurd attempts to prevent spoofing  
become.  I want to take this even further and not even allow DKIM to  
assert this restriction.  Already you offer a mode that will be  
highly disruptive.  DKIM must not care about spoofing.  DKIM should  
only ensure the validity of the signing domain's signature.  Leave  
everything else as second semester work.
Clearly those domains under attack require additional protections.   
By listing those domains and using deterministic conventions (DKIM as  
example), this problem could be better abated without resorting to  
binding headers with domain-wide assertions through a stack of what  
is and is not allowed.  In the end, expect even "no holds barred"  
efforts to result in only partial success.  The phishing problem is  
multifaceted.  Ensuring the From address is not enough.  This problem  
involves embedded links within HTML messages as much as it does email  
addresses.  Treat this problem separately and take it off the DKIM  
table.

> > 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.
> The List-* headers are well-defined, but many MUAs probably do
> not display them (by default).

How is this a problem?  The message provides an immediate  
"accountable domain" in the case where the signed message is not  
altered.  I would also assume the signature would permit the list's  
header to be added.
What is seen by the recipient is well beyond DKIM's control.  Even  
binding headers does little to improve upon this.  Start with small  
steps.  Get the "accountable domain" in place first.  In time, it  
will become more apparent what the next steps should be.  The  
"accountable domain" is more than enough for now.
-Doug



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