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

On Aug 23, 2005, at 8:09 PM, Earl Hood wrote:

> On August 23, 2005 at 16:13, Douglas Otis wrote:
>
> Let's take a real-world example.  CPAN provides a permanent email
> address for all CPAN account holders.  CPAN account holders specify
> where to forward all messages address to their CPAN addresses.
> This type service is not unique and provided by multiple entities,
> e.g. SourceForge, Savannah, college alumni services, etc.
>
> Now, is there value for CPAN to DKIM sign messages that it forwards?
Any email provider, regardless of their role, must remain vigilant.   
Whether they sign their outbound mail or not, there remains risks of  
being black-hole listed, should their servers become abused.  On the  
value side, DKIM provides solid evidence where a problem originated,  
and will likely be coupled with tools automating this reporting.   
With DKIM, there is finally assurance reports are being sent to the  
accountable entity.
Receiving these reports based upon signed messages can also be easier  
to process.  After all, reports of abuse will likely be from some  
other third-party, where the signature improves the trust model there  
as well.  There is a serious flaw in the DKIM protocol that leaves  
any DKIM signer exposed, and also limits the reporter's ability to  
correlate abuse.  This would be with respect to the potential for  
message replays, and a lack of a domain-cookie.  However, the same  
tools needed to track abuse will also allow the DKIM signer to create  
their own lists to revoke accounts that have proven abused.
The value or advantage provided by DKIM would be from automation in  
respect to keeping servers clean.  Having DKIM as a authentication  
scheme coupled with domain-cookies would be to the benefit of the  
recipient, as there would be greater expectations that abuse would be  
dealt with swiftly.  Also from the user perspective, the domain- 
cookie coupled with the signature could provide opportunistic  
identifications of their correspondents.
Over time, as more of the messages are received already signed, there  
could be an advantage to not re-sign the message.  This would not be  
to hide from the problem, but to allow reports to reach as close to  
the source as possible.  I suppose adding two signatures would be  
another way to say "copy me on any problem seen, but be sure to send  
reports to the source."  I like the cleaner one-signature approach,  
but there could be two interested parties with respect to abuse  
reporting.

> If so, should it be held as accountable for those messages as the
> originating domains of the messages?

In my view, there is no escaping accountability.  The best  
protections are established when messages are signed.  Speed is the  
best prophylactic.  Either the evaluation will be based upon the IP  
address, which carries a set of risks, or the stronger domain  
signature.  When accepting signed messages with a good reputation,  
there are some tests that may improve confidence.  When the HELO  
differs from the signing domain, a revocation check could be made by  
doing an 'A' record lookup on the domain-cookie.  When a record is  
returned (no DNS error), simply refuse the message.


> If it should not sign, why, and does this go against the goal of
> trying to get everyone to sign messages?

DKIM raises the bar.  Your statement seems to imagine ensuring  
accounts are not being abused would not be in the interest of the  
sending domain.  I strongly feel, that with DKIM in place, new  
standards of excellence will be difficult to meet without signing all  
outbound mail and processing reports.  DKIM could be seen as a type  
of abuse report automation.  The individuals are kept anonymous, but  
abuse can be rapidly correlated and sent to the administrator able to  
take immediate action.

> > Not re-signing a message already signed makes good sense.
> I would not use the term "re-signing".  I am talking about adding a
> signature.  Re-signing implies any existing signature is invalidated
> and/or removed.
>
> It all goes back to my discussion about roles.

The role would not be important.  Getting as close to the source  
would be where the checks should be made.  Adding an additional  
signature would only seem to be saying, "Keep me in the loop.  I want  
copies of the problems."

> > Passing
> > unsigned messages retains the tracking difficulty which benefits no
> > one but the abusers.
> So CPAN should be held to the same accountability standards as the
> originating domains?

Really, what is the difference?  Are they somehow more virtuous by  
promoting their domain in this manner?  Any domain sending mail runs  
the same risks, and must take the same steps.  An abused account must  
be terminated.  Abuse reports must handled. etc. etc.  It does not  
matter whether this is based upon the IP address or the domain  
signature.  I simply see DKIM as the easier path for the domain  
administrator. (Provided a few things are fixed.)


> If accountability is fixed, CPAN has no, and should not, claim any
> accountability for the messages that pass through it.  Therefore,
> signed or not, CPAN will not sign any messages to avoid undesired
> and unwarranted accountability.

All not signing does is limit their visibility of the problem.  Any  
domain will be held accountable, the question is whether it is name  
based or IP address based.  Some exploits make defending a signature  
look better every minute.

> The only motivation for CPAN to sign messages is if the signature
> is a "transmission signature" to provide a verifiable trace of the
> message, and not to claim any form of accountability on the content
> of the message.


Every provider could claim they are only offering message transit and  
are therefore innocent.  If they permit abuse and are not monitoring  
their logs, or abuse reports, they are not that innocent.  Vigilance  
is a cost of doing business.  It is an unfair cost, but a cost none  
the same.

> If transmission signature are deemed to have no real value, then we
> should throw out the goal of trying to get every entity to sign
> all messages it processes.

I think DKIM raises the bar.  Turning ones back on automation in this  
critical area would find themselves left in the dust wondering what  
to do with their buggy-whips.


> I agree that rfc2822 originating headers are an issue since there
> is a reliance on MUA rendering characteristics.  For MUAs that
> are DKIM-aware, it is a non-issue since the proper rendering to
> the recipient can be done.

Perhaps the only consideration that would need to be made would be to  
indicate the level of binding that an MUA needs to  capture from a  
message in the signature header.  During the capture process, show  
the user the signing domain.  There is no need to muddle with a  
complex matrix of authorizations.  By trying very hard not to deal  
with mailbox-addresses, more is accomplished in ensuring the cost of  
using DKIM is kept low.  Support cost is where acceptance risks exist.
For phishing, most of this is attempting to take advantage of  
existing relationships by mimicking prior correspondences.  A hyper  
defensive MUA could notice when the binding only requires the mailbox- 
domain, and the signing domain matches, the binding could be asserted  
in an automated fashion.  This would significantly harden the typical  
target without ever exchanging semaphores in DNS.  Any initial  
message never before seen should prompt suspicion.  A prompt to bind  
the information should expose the signing domain and permit permanent  
exclusion of the message.  Again, DNS authorizations are not  
required, just the key and some flags in the signature header.

> The problem is with non-DKIM-aware MUAs.  There may be solutions
> to address this with verifiers running at the MTA/MDA level that
> "re-write" the message for display any non-aware MUAs.

It would be faster to create industry generated lists of those sights  
that conform to some new conventions permitting deterministic  
checks.  There are issues with pretty names, look-alike domains,  
unseen headers, etc.  DKIM and this type of list could provide a  
means to establish more immediate stop-gap measures.  It seems  
foolish to add complexity that will bog down deployment, when this  
extra administrative rubbish is not needed for the long haul.  I  
would be in favor of showing that the basics work.  Establishing a  
domain that can be held accountable before attempting to add other  
layers of complexity.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org