ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

2005-08-20 17:18:06
On Sat, 2005-08-20 at 13:08 -0400, Scott Kitterman wrote:
Douglas Otis wrote:

Defensive strategies must find a different identifier assured by the  
domain as a unique basis for locating trouble.  This is simply being  
pragmatic, but this new identifier will not impact the way email  
operates, as would adding constraints on the mailbox-domains.  MASS  
should adhere to an oath that above all, do no harm to remove all  
excuses. : )

You can't stop forgery without stopping forgery.  Some things that are 
perhaps technically forgery are considered desireable.  Other things 
that aren't forgery might be affected by forgery prevention protocols.


Stopping forgery requires a system analogous to S/MIME or OpenPGP.
Anti-forgery may be seen as a cause to garner support.  However, in
reality DKIM is ill suited to satisfy such a goal directly.  DKIM has
the limited scope of _just_ the signing domain.  Forgery or non-forgery
can not be directly determined by the signing domain.

There is no practical benefit attempting to conditionally select headers
that must share the domain of the signature.  Headers may not be
displayed, or displayed by the pretty name.  The mere option of the
binding and the possible lack of display seriously erodes any presumed
value, but increases susceptibility to fraud, which would be a dubious
cause for garnering support.

Should this already dubious effort pursue greater complexity by
extending this optional binding authorization scheme to include
extensive tree walking for possibly dozens of mailbox-addresses to
discover their domain-wide binding assertions.  Should there be specific
permission lists assessed for each of these mailbox-addresses, to decide
whether the signing domain is authorized to send such re-submitted
messages?

Won't this cause far more trouble than it could be possibly worth? 


I'm not on a 5-10 year timetable that says things get better after the 
whole world upgrades.

I don't believe it is possible to have any near-term positive effect 
without also having some potential for near-term harm.  DKIM should 
allow for restrictive policies for domain owners that are willing to 
live with the side effects of those policies.


Breaking email in the near term, for half measures trivially evaded,
will not garner support.  Feeble half measures still impact those who
want nothing to do with troublesome and ill-conceived schemes.  Email
can least afford dealing with support issues due to changes in
previously valid procedures.  Worse, new limitations in email address
re-submission increase costs, risk expectations of deployment, while
abusers still slip past these troublesome email address obstacles.


I ask you which would be worse for a commonly phished domain, that their 
messages would fail verification if sent to a mailing list or that 
forgeries of their domain would continue to be delivered to end users?


As phishing involves much more than spoofing the From address (which
even the current DKIM draft does not prevent), there needs to be a
different strategy.  To combat phishing, Draconian conventions must be
followed with respect to _all_ aspects of the email message.

The number of checks such anti-phishing efforts entail, means these
checks may be best limited to an industry list of specific domains.
DKIM can play a vital role by indicating the signing domain, to offer a
solid basis for detection.  Anti-phishing's extensive checks could be
placed at risk when applied universally or perhaps when applied upon
request by any sender.


I expect that many domains would be willing to give up mailing lists for 
a way to enable receivers to detect and reject forgery of their domain 
during the SMTP session.


The term forgery with respect to DKIM is misleading.  Email did not
achieve its current scale of deployment by checking authorizations for
every possible entity contained within a message.  Instead email depends
upon a hierarchy of trust or accountability.  It would be a significant
achievement having the DKIM signature, with perhaps even the HELO,
verified.  Such domain level authentications greatly strengthens this
trust and accountability.  The basic operation of email would not
change, yet an ability to exclude those known for abusive behavior would
be dramatically improved.

Use of a name would cause less collateral blocking.  A name can rely
upon a history specified by the registrars, even though specific
information of who owns the name may be concealed.   Just this
fundamental ability can help abate all these cause Celeb abuses.


I think it's DKIM's job to give them the choice and the information to 
make an informed decision.

First do no harm is fine if the patient isn't dying already.


Unfortunately, problems are not constrained to just email.  Header
binding From is cosmetic when done "some of the time" and does not
consider pretty names.  This binding will not breath life into email,
but rather it will create problems for users, and likely discourage
adoption, and encourage those committing fraud. 

DKIM should verify a domain that can be held accountable for stopping
abusive messages.  (It would be nice for the recipient to see who is
accountable.)  However, displaying the accountable domain is not needed
and should not be attempted with feeble header bindings.  With DKIM,
administrators can ensure bad actors are excluded.  With DKIM, creating
a list of trusted domains will exclude most of the emails which need
greater examination.

I like the "profound" quote from the comedy City Slickers. Jack Palance
played trail boss Curly Washburn and said "Do you know what the secret
of life is?  One thing.  Just one thing.  You stick to that, and
everything else don't mean s***."  DKIM should do one thing.  Verify a
domain that can be held accountable for stopping abusive messages.

-Doug



 


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

<Prev in Thread] Current Thread [Next in Thread>