Charles Lindsey wrote:
> On Thu, 04 Nov 2010 02:04:16 -, Hector Santos wrote:
>
>> It is (A) that is most important here and this is where the corrective
>> text should be added. The original ISSUE Posting included proposed
>> text to follow the "last header" paragraph in Section 5.4:
>>
>> Special Consideration for Verifying and Signing From: Header
>>
>> As an exception, header hash verification MUST be done for all
>> 5322.From fields and not just the last one. Signing MUST be done
>> for all 5322.From fields found, even though RFC5322 recommends
>> only one 5322.From should be used. This will mitigate any
>> replay that prepends a new 5322.From header to a DKIM signature
>> valid message. Some MUAs have shown to display only the first
>> 5322.From header found.
>
> + 1/2
>
> You seem to imply that hash verification MUST be done for all From
> fields both during signing AND verification. Fine! You say exactly what
> is to be done when signing, but leave it unclear what to do if a
> verifier hashes all the From:s it can find, but finds there are
> insufficient of them listed in the 'h=' tag.
>
> So I suggest you add the following:
>
> Verification MUST check that all 5322.From fields found have been
> included in the signature. This will mitigate any deliberate omission
> to sign some 5322.From (such as the first, which might be the only
> one displayed by some MUA) by a malicious signer.
+1.
I guess I as a bit bias because the DKIM API I was using had already
resolve this issue with an option:
Allow Unsigned From Headers
which was an extra option and by default is zero (OFF, FALSE,
DISABLED) hence each 5322.From header found were checked against the
h= list of tag values.
Think of how a verifier migh parse this stuff. While there could be
different methods, a typical model is a streaming line parser:
while ReadNextLine(line) do
DKIM_VerifyLine(Line)
wend
As it reads the headers line by line, it checks the h= tags to do the
hashing. The method used in this DKIM API is to remove the h= tag
value as it matched and rehashed the header as it rebuilding the
signature hash.
So when it found the first 5322.From, it checked, hashed and removed
the "from" tag from the list of tags in h=.
If another 5322.From was streamed in, the special IF statement for
"Allow Unsigned From Headers" checked to make sure there was still a
h=from tag for it. If not, an invalid signature result was immediately
returned.
Think of this option as a "plug and play" extra requirement which
allowed an operator to revert to the original 4871 described behavior
if the option was enabled. When enabled, the presence of a 2nd
5322.From did not violate the 4871 Section 5.4 logic.
My text was basically trying to keep with the idea that its
(erroneously) possible to have an extra 5322.From header but the DKIM
protocol "extra requirement" would enforce only one to be hashed. So
by saying "header hash verification MUST be done for all
5322.From fields and not just the last one," it will help keep with
the current logic in Section 5.4 but also help create the invalid
signature we are looking for from a "plug and play" aspect.
> And furthermore, I would suggest replacing "5322.From fields" by
> "once-only fields" (where "once-only" is defined as some explicit list
> of headers derived from RFCs 5322, 4045 and maybe others - precise
> contents to be discussed separately).
True. I'm on the fence with that though to the extent here required as
I think the main focus should be with the security issue here which is
mostly with 5322.from since it is the only required DKIM binding for
headers and arguably the #1 Display Header to be concern about.
But sure, even if generic text is used here, it should probably have
an i.e, or e.g, for 5322.from to make sure the prime focus is the main
security reason for these extra considerations.
--
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
