Subject: [ietf-dkim] NEW ISSUE: Security Threats are well defined

From: Hector Santos <[email-masked]>
Date: Mon, 11 Feb 2008 20:07:11 -0500

Section 5 is pretty clear about security threat potentials about removed 
all considerations in SSP-02 to deal with them.

| 5.  Security Considerations
|
|   Security considerations in the Sender Signing Practices are mostly
|   related to attempts on the part of malicious senders to represent
|   themselves as other authors, often in an attempt to defraud either
|   the recipient or an Alleged Author.
|
|   Additional security considerations regarding Sender Signing
|   Practices may be found in the DKIM threat analysis [RFC4686].
|
|      *<<<THIS SECTION IS NOT COMPLETE.>>>*

I suggest the following be added in part or in whole to the section:

   There are clear and present danger with high potential frauds which
   SHOULD NOT be ignored if we are to gain any payoff or add-valued
   secured benefit for signers, verifiers and users:

   The fraud are exhibit when transactions contradict the following
   domain expectations:

     o NO MAIL EXPECTED
     o OPTIONAL 1ST PARTY SIGNING ONLY
     o STRICT 1ST PARTY SIGNING ONLY
     o 1ST OR 3rd PARTY SIGNING REQUIRED

   These represent the key propositions in the protocol consistency of
   the DKIM model and they can offer immediate and high potential
   security protection against current legacy domain forge abuses and
   expected DKIM-adapting mail abuses.

   Please keep in mind that these are not signature or domain reputation
   evaluators but fundamental DKIM protocol consistency checks.  It may
   be viewed a "DKIM Policy Declaration" Checking.  In addition, there
   is no verifier mandated handling requirement. All handling language
   recommendations cited below are defined by RFC2119.

   o NO MAIL EXPECTED

     One of the largest abuse of domains are forged mail transactions
     which are using RFC2822 From: domains which are not valid Email
     hosting domains and/or were not expected to be used for email
     transaction by the principal owner of the domain.

     Protection is offered in SSP-02 as follows:

     Domains can implicitly state mail is not expected by creating a NULL
     public key to force invalidation of a signature. Augmenting this
     with a DKIM=DISCARDABLE enforces the requirement of a valid
     signature, therefore with the lack of valid signature, the message
     SHOULD be rejected without prejudice.

   o OPTIONAL 1ST PARTY SIGNING ONLY

     Conventional wisdom suggest that domain explorers of DKIM
     will test the waters using an optional 1st party signing
     policy.  Some messages will be signed while others are not,
     but they don't expect 3rd party signers to "test" the waters
     for domain.

     Unexpected 3rd party signing protection is not offered via SSP-02.

     A new explicit policy DKIM=OPTIONAL is recommended that
     distinguishes itself from the current DKIM=UNKNOWN which allows
     anyone to sign and misrepresent the domain.

     DKIM=OPTIONAL (NEW)

     This policy declares the domain signing practices are optional, but
     only expect its own domain to sign the mail.  No other 3rd party
     representation is expected.  A message containing a 3rd party
     signature SHOULD be rejected without prejudice.

   o STRICT 1ST PARTY SIGNING ONLY

     This protection is offered using DKIM=DISCARDABLE. A message with no
     signature or containing a 3rd party signature SHOULD be rejected
     without prejudice.

   o 1ST OR 3rd PARTY SIGNING REQUIRED

     A weak protection is offered using DKIM=ALL. It is weak because it
     allows for an inconsistent state to exist without prejudice and
     lacks handling semantics for the detectable inconsistent DKIM=ALL
     policy transaction. A message with no signature or containing a 3rd
     party signature MAY be rejected without prejudice.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html