[ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From

[Hector Santos]

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)
     mail system."

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 
ourselves.

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 
protocol.

This one chalks up as on par with what we are seeking.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com