I will not pretend to know (nor really care) what it will take to get
over this documentation dilemma but I will provide my comments here:
Murray S. Kucherawy wrote:
8.14 Malformed Inputs
DKIM allows additional header fields to be added to a
signed message without breaking the signature.
DKIM does not "allow" additional header fields. It just didn't check
for conditions that were problematic. If this issue was obvious back
during the TA work, we would not say this and the checks (exceptions)
would be incorporated in Section 5.4 today.
A better "friendlier" opening theme sentence is:
There are known conditions which can alter the originality of a DKIM
signed message without breaking the existing signature validity.
This tolerance can be abused, e.g. in a replay attack, by adding
additional instances of header fields that are displayed to the end
user or used as filtering input, such as From or Subject, to an
already signed message in a way that doesn't break the signature.
This is close, but again, there is no "allowance" or a "tolerance"
because, for the most part, DKIM was essentially "ignorant" of the
conditions due to lack of vision during the TA. So I think the text
following the opening theme could be:
Since it is possible to maintain the integrity of the signature with
these known non-compliant RFC5322 message alteration conditions,
there
is an increase possibility of abuse and exploitation of MUA
displaying
information which were not validated by the signature. Examples may
be non-compliant RFC 5322 messages containing a 2nd 5322.From or 2nd
Subject headers which were not hash bound to the DKIM signature,
yet due
to the nature of MUAs, the wrong header could be displayed to
end-users.
The resulting message violates section 3.6 of [MAIL].
What resulting message? The one DKIM ignorantly neglected to check? I
think my text above covers the "blame" and IMO this sentence can be
pulled.
The way such input will be handled and displayed by an MUA is
unpredictable, but in some cases it will display the newly added
header fields rather than those that are part of the originally
signed message alongside some "valid DKIM signature" annotation. This
might allow an attacker to replay a previously sent, signed message
with a different Subject, From or To field.
I think handled and displayed can be seen as two different things or
levels.
Backend handling can be very predictable, Frontend displayed may not
be since the MUA can be online or offline. Online can be predicted,
offline less predictable but the odds are very high that what is shown
offline will match what would be shown online for the simple reason
systems that offer both modes take these offline vs online ergonomical
issues into account to the best of its ability.
We want the offline experience to match that of the online experience.
We author a variety of MUA software from offline to online. Overall,
there are certain messages headers that are expected to occur only
once and thus including the overhead to parse or check for a 2nd or
more header may not even be a considerations for some and even if it
was, it could be viewed as redundant overhead.
So its very predictable most parsers will mostly use the first header
found and the only thing that is unpredictable is whether these
special redundant overhead double header conditional checks are
performed to a wide degree.
I would change this to:
It is unknown how these non-compliant RFC5322 messages will be
handled by
backend MTA receivers and how MUAs will display them. It is
conceivable,
some MTAs will reject these messages while other MTAs may accept it
but only after it has sanitize the message for user display. Yet other
MTAs may be unaware of the multiple headers in these non-compliant
RFC5322 messages.
Under unchecked conditions, this can allow an attacker to replay a
previously sent, signed message with a different Subject, From or To
field.
Because of this, DKIM implementers are strongly advised to reject
or treat as suspicious any message that has multiple copies of header
fields that are disallowed by section 3.6 of [MAIL], particularly
those that are typically displayed to end users (From, To, Cc,
Subject).
I am not sure about this. More below.
A signing module could return an error rather than generate a
signature; a verifying module might return a syntax error code
or arrange not to return a positive result even if the signature
technically validates.
I am not sure about this because there are variations of solutions and
I don't think the above covers them all.
I would like to see something more generic that could cover in general
the different ways DKIM processing may be integrated.
Maybe text like:
Despite the apparent scope of this requirement, there are
implementation circumstances in which how DKIM processes
these non-compliant RFC 5322 messages not be determined until
it is known how messages are first passed or reach integrated
DKIM processors.
With an increase alertness of the possibility for these
non-conforming RFC5322 yet DKIM compliant messages, receiver
MTA may begin to perform this filtering at an increase level.
This form of processing will minimize any implementation
requirement for DKIM to perform this non-compliant mail check.
In addition, enhanced MUA operations can address the situation
as well with attentive awareness of non-compliant message displays.
Senders concerned that their messages might be particularly vulnerable to
this sort of attack and do not wish to rely on receiver filtering of
invalid messages can ensure that adding additional header fields will
break the DKIM signature by including two copies of the header fields
about which they are concerned in the signature (e.g.
"h= ... from:from:to:to:subject:subject ...). See Sections 3.5
and 5.4 for further discussion of this mechanism.
I would change this to:
To address current or legacy email implementations that may not
aware of these non-compliant RFC 5322 double header messages, DKIM
Signers concerned their signed outbound messages might be
particularly vulnerable to this form of attack can ensure that
adding unexpected additional header fields will break the DKIM
signature by including two copies of the header fields about
which they are concerned in the signature h= tag e.g. "h= ...
from:from:to:to: subject:subject...". See Sections 3.5 and 5.4
for further discussion of this mechanism.
--
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