Douglas Otis wrote:
Ensuring multiple header fields stipulated as occurring once not provide
a deceptive DKIM result does not alter the intent of DKIM validation.
It is important for DKIM compliance to ensure deceptive and invalid
header field instances are excluded by the verification process from
returning valid signatures. Clarifying this stipulation to establish
proper verification layering will not raise interchange issues.
These checks must be part of any DKIM compliance certification program
or recipients are at risk. Language in the base specification must make
this requirement clear. After all, it was missed and exploited with
DKIM's implementation used by the WG mailing list, if anyone needs examples.
It would be unwise to invest either trust or services in an easily
exploited system.
Hi Doug,
I can imagine in the ideal DKIM integrated world where One From is
signed and the verifier will only validate One From and the Display
Renderer only using One From validated by DKIM, there would some
design considerations where the all parts will eliminate or ignore any
additional From headers, if any, that is not part of the successful
validation.
For example:
1) The signer gets a proper RFC5322 message with only one 5322.From
header:
From: GoodGuy
Signs the message and its out into the mail stream.
2) Some how, one way or another, additional 5322.From headers are
injected into the message headers, so now you have:
From: BadGuy1
From: BadGuy2
From: GoodGuy
From: BadGuy3
and it doesn't matter what order.
3) The in the ideal DKIM verifier, it will test each From:
- Hashing From=BadGuy1, the signature fails.
- It sees another from=BadGuy2, tries that in the hash, it fails.
- It sees another from=GoodGuy, tries that in the hash, it validates
and he stops here.
So the question, as I see it, is what is reported?
- Validate, but has suspicious invalid extra From?
- Validate, removes any invalid extra From? or,
- Invalidates due to extra from headers?
In my view, its possible since the verification is local, if its using
a local display renderer, it could just show the valid from and ignore
the rest.
The problem that I see is when there is store and forward, i.e. pop3.
What does the POP3 server do here as it prepares the data to be
transmitted to the pop3 client? Should it strip the invalid extra from
headers? Or do we assume the POP3 client or rather the offline mail
reader will be multi-from security DKIM aware like the online system?
In short, the host system and/or verifier/receiver can do a lot here,
but I personally don't like to be playing these games and we don't
know how other software will behave, so I would prefer to just kick
out damaged mail - even when its possible to validate one of the
multiple froms.
--
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