John R. Levine wrote:
Presumption of RFC5322 compliance is the mistake made in DKIM and ADSP.
50% agreed. This mistake is only in DKIM, IMHO.
At this point, it would be helpful if you could propose specific language
for 4871bis. And if it's not presuming 5322 compliance, it would also be
helpful if you could say in detail what a DKIM signer and verifier should
do if presented with, say, a Windows executable file. Not a MIME encoded
message body containing one, just an EXE file. If you don't require 5322
compliance or something close to it, that's as legitimate a signing
candidate as anything.
Based on the discussions, providing the proper technical does not seem
to be problem, but rather how it conflicts with satisfying IETF RFC
passage guidelines to avoid yet another WG review cycle.
All that aside..
IMV, it was not a mistake to presume 5322 compliance. All mail
processing components begins with that basic design presumption.
But it was mistake to presume specific DKIM related input requirements
can be violated or incorrect and yet be ignored or not checked due to
the subjective software engineering idea that it a protocol Layer
violation and thus isn't a DKIM technical responsibility to make sure
these DKIM related specific input parts are correct.
In other words, since a RFC5322 presumed compliance carries over a
concept that there MUST be only one 5322.From, there is a solid
Software Engineering (SE) design consideration for the DKIM input
requirement protocol to take this into account. A robust function
generators will check for its boundary conditions and the mistake is
in the failure to recognize this SE design consideration.
While it is a valid SE consideration to avoid this is an optimization
or lower overhead consideration, but that should not preclude the idea
that the SE design semantics not be part of the functional specification.
For example:
Section 5.4 speaks in generic terms regarding signing the last
instance (from the top, with the presumption that this last instance
is the first introduction of the header) only but failed to highlight
the design requirement for a specific single field only 5322.From
requirement as it relates to a) RFC5322 correct DKIM signature output
and b) RFC 5322 compliance itself.
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.
With all the WG participant since then, the above can be better
clarified, but my main point here is that Section 5.4 is where the
reader is learning how to implement the logic related multiple headers
and it is here where the reader should be quickly made aware of the
RFC5322 compliance reminder and exception to the "Last Header" guideline.
I think a new security Section 8.14 is needed to further describe the
"reason" for the exception in 5.4. I think my version is better than
Murray's but I don't really care about that.
Probably, what is also needed that will really help implementators are
"tips" and "methods" to address this with an eye to how realistically
DKIM components are added or integrated to a system. But I believe
this can be done first by simply stating:
DKIM implementators can mitigate this issue by adding 5322.From
checking
in their verifiers and signers. The 5322.From checking can also
be done
at the integration points such as MTA receivers.
The problem is the next statement because it appears to have IETF
conflicts:
It is HIGHLY RECOMMENDED for all DKIM verifiers to ALWAYS perform a
multiple 5322.From header check and return an invalid signature when
two or more 5322.From headers are found.
Putting aside the IETF conflicts, by making this a new fundamental
4871bis requirement for DKIM verifiers to perform this check, it would
be begin to address the problem to a very high degree.
But at the end of the day, it is an integrated solution. DKIM can not
work by itself. It works when integrated with other parts; MSA, MDA,
MTA, MLS/MLM and MUAs both online and offline.
As a generic protocol, DKIM can offer a solution for this specific
multiple 5322.From header fault at the verification and signing
process and we should provide DKIM software writers the insight to
consider it when providing tools to the DKIM integrators. It will be
the DKIM integrators who will decide how to use the DKIM tools
provided depending on what the other integrated parts can do or not do.
The "total" solution is an integrated one and since this belated
highlighted ISSUE has now shown it is also a problem for non-DKIM
streams, integrators are now smarter about the issue and will most
systems will begin to do more RFC5322 checking prior to any DKIM
processing or display to users.
--
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