On Tue, 26 Apr 2011 02:33:11 +0100, Douglas Otis <[email protected]> wrote:
> Although DKIM is reviewed within IETF's security area, input validation > by DKIM remains dangerously neglected. DKIM's Introduction indicates it > can be implemented independent of clients. As such, few assumptions are > safe in how users become aware of DKIM's intended protections or > acceptance policies. > > The Security Considerations Section 9.14. Attacks Involving Addition of > Header Fields states: > ,--- > To resist this specific attack the signed header field list can > include an additional reference for each field that was present at > signing. For example, a proper message with one From: field could be > signed using "h=From:From:..." Due to the way header fields are > canonicalized for input to the hash function, the extra field > references will prevent instances of the cited fields from being > added after signing, as doing so would render the signature invalid. > '--- > > Double listing in the "h=" tag can not fully mitigate risks related to > appended header fields when messages are signed by a different domain > than the domain found in the appended From header field. Users may > depend upon their employer's or their provider's policies using methods > similar to those used with ADSP which requires Author Domain > Signatures. Whether policies result from a domain publishing ADSP > records or through private arrangements, these policies may still be > circumvented with appended header fields. I have proposed some alternative texts for this in a separate thread, and Murry seems happy to accept them, so that is a slight degree of progress. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: [email protected] Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
