ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Getting resolution on the "double header" issue

2010-11-15 14:41:08
On 11/12/10 9:35 AM, Charles Lindsey wrote:
On Thu, 11 Nov 2010 17:55:55 -0000, Douglas 
Otis<dotis(_at_)mail-abuse(_dot_)org>
wrote:

Once one DKIM verification vendor includes these necessary checks that
suppress DKIM PASS, and another vendor does not, DKIM implementations
are no longer compatible.  IMHO, this represents a DKIM protocol failure
to properly define elements that MUST BE checked to qualify a DKIM PASS
verification result.  The DKIM protocol may require future updates as
new exploits are discovered, or a significant design goal will have been
lost.
Actually, for the particular problem we are considering, this will not
arise.

In the scheme I have proposed, the Signer MUST do X and the Verifier MUST
check that the Signer had done X.

However, X only arises where there are multiple once-only headers (so the
message is already 5322 incompatible). So even if the (old) signer fails
(to sign both in this case), the (new) verifier is then merely rejecting a
message that was 5322-incompatible anyway, which is no big deal.
Disagree. Unless a DKIM verifier MUST NOT return PASS for messages with 
multiple once-only (singleton) headers, DKIM results can not be 
trusted.  In such a scenario, pre-pended singleton header fields are 
beyond the control of an Author Domain when two From header fields exist.

For example:
  From: accounts(_at_)big-bank(_dot_)com
  From: someone(_at_)big-isp(_dot_)com
  DKIM-Signature: d=big-isp.com; ...

It does not matter how big-bank.com signs, the verification process MUST 
check for multiple singleton header fields to prevent many types of 
exploits.  Double entries for all singleton header fields within the h= 
parameter is wasteful, where full protection requires universal 
adoption.  It would be ridiculous to expect adoption by bad actors.

Only by the DKIM protocol mandating a MUST check for multiple singleton 
header fields by the verifier, will these exploits be prevented.  
Without this requirement, DKIM has little meaning.  DKIM's design goals 
can not be met by expecting critical checks to be made elsewhere.  These 
checks are normally not needed and not made since without DKIM, there is 
no trust based upon the DKIM signing domain to be exploited.

Clearly, the DKIM protocol failed to be explicit about this 
requirement.  Only by making the verifier requirement explicit, can DKIM 
compliance provide trustworthy results and compatible implementations.

-Doug






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