On 11/12/10 9:35 AM, Charles Lindsey wrote: > On Thu, 11 Nov 2010 17:55:55 -0000, Douglas Otis<[email protected]> > 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: [email protected] From: [email protected] 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
