John R. Levine:
a) Author creates a 100% compliant message
b) Signer signs 100% compliant message
c) Bad guy adds an extra header, making it non-compliant, and
sends it to someone
...
Mike, I only have vague recollection of the h= trick anymore...
You list all the headers you sign in h= list, and you can include headers
that don't exist, which means that they can't exist when verified either.
So for a header that occurs N times, you can list it N+1 times in h= to
ensure that more aren't added. The original motivation was usually N=0 to
avoid games played by adding MIME headers to messages that don't have
them, but it's generally applicable.
With this signer-side configuration solution, the verifier can
detect attempts to "spoof" any header that was covered by the DKIM
signature (spoof as in "add a forged header, and hope that naive
programs will use the forged header instead of the authentic one").
So the solution is already available in DKIM. We just need to use
the solution, and make it part of routine DKIM tests.
Having the signer put the extra junk in h= should make existing verifiers
do the right thing, although I doubt the bit of verification code that
checks for the non-existence of the N+1st header for N>0 is well tested in
DKIM implementations.
To address this, make this solution part of routine DKIM test suites.
Wietse
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html