[ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
hsantos at isdg.net
Tue Oct 5 08:58:10 PDT 2010
Ian Eiloart wrote:
> --On 4 October 2010 18:24:11 -0400 Hector Santos <hsantos at isdg.net> wrote:
>> It has been observed by implementations that is it possible to replay
>> a message with a 2nd 5322.From header at the top which wouldn't break
>> the DKIM signature validity, but would often be displayed by MUAs to
>> display the new 5322.From display rather than the signature bound
>> 5322.From header.
> Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to
> display the signed header? Are there really MUA's that will display the
> unsigned headers *and* assert that it was validated? If so, that's
> surely a bug in the implementation of the MUA.
Ian, it would be not practical to expect MUAs to address this. But
sure a recommendation for MTAs and MUA to validate RFC522 specifically
in regards to 5322.From would suffice.
As Keith Moore recently stated in IETF-822:
"Okay, I'll state it with more precision: The checking of
headers should only occur when such a feature is actually being
used: e.g. when the message is actually being submitted, being
filtered for spam specifically on behalf of a sender or recipient,
or being gatewayed into (or out of) a foreign (non-Internet)
His point, in IMV, is that you are not going to find many MTA doing
RFC 822/2822/5322 checking unless it has a specific purpose.
A DKIM ready ADMD or MTA receiver might be able to reject/drop invalid
mail with multiple 5322.From lines. We added a script for this
But to cover all loopholes the DKIM-verifier MUST have an additional
requirement to fault a message with 2 or more 5322.From lines.
That is exactly what the ALT-N open source DKIM/ADSP API did - added
an additional requirement for DKIM verification that is above and
beyond what the current specs says and currently allows.
The whole point of a BIS is to help codify the implementation field
testing and experiences which alter or fine tunes the proposed draft
This one chalks up as on par with what we are seeking.
Hector Santos, CTO
More information about the ietf-dkim