Others have pointed out the weakness of the "nowsp"
standard for canonicalizing a message. Four items stand in the way of
adoption of a stronger canonicalization routine:
1. Justification must be made for a stronger standard.
2. Additional text must be inserted into the draft.
3. A sample implementation or two must be supplied.
4. A consensus must be achieved to accept the above three.
I will cover the first three items and leave the forth to feedback from
this community.
1. Justification
The nowsp form of canonicalization allows for a man-in-the-middle attack
that can alter critical headers or the message body. For example, the
following Subject header:
Subject: Amoeba yeast
Can be changed during transit into:
Subject: Amo ebay east
without altering or invalidating the hash. Similar attacks can be made
against the body by rearranging text to form pictures or new phrases or
simply to make the text an embarrassment to the sender. I won't give
further examples, because they are easy to invent.
The DKIM standard will suffer if such attacks happen after deployment.
The more widespread DKIM becomes the more serious such attacks will become.
2. Wording
I propose that the following wording appear in the draft:
3.4.3 The “onewsp” canonicalization algorithm
The “onewsp” algorithm replaces each multiple contiguous SWSP in all
lines to a single space and unwraps header field continuation lines.
These rules MUST be applied in order.
* Unwrap header field continuation lines so that individual header
fields are processed as a single line. No SWSP should be removed during
this step; in particular, implementations MUST NOT remove the colon
between the header field name and header field value and MUST NOT remove
the terminating CRLF on individual header fields.
* Map all header field names (not the header field contents) to
lower case. For example, convert “SUBJect: AbC” to “subject: AbC”.
* Convert each contiguous sequence of one or more SWSP characters in
the header field name and header field value into a single
space character. SWSP is defined in [XINDX].
* Convert each contiguous sequence of one or more SWSP in the body
into a single space character. If one body line ends in SWSP and then next
body line begins with SWSP, the ending and beginning sequences must be
interpreted as a single combined sequence and both together replaced
with a
single space character.
*One CRLF between the end of the last header field and the body is
included in the hash computation and is not converted to a single space.
INFORMATIVE EXAMPLE: A message reading:
A: <SP> X <CRLF>
B: <SP> Y <CRLF>
<SP> Z <CRLF>
<CRLF>
C <CRLF>
D <SP><TAB><SP> E <CRLF>
<TAB><TAB> F <CRLF>
is canonicalized to:
a:<SP>X<SP>b:<SP>Y<SP>Z<SP><CRLF>C<SP>D<SP>E<sp>F<SP>
After the body is processed, a single CRLF followed by the
"DKIM-Signature" header field being created or verified is presented to
the algorithm. The contents of the "b=" tag, if any, MUST be deleted,
and the header field must be canonicalized according to the algorithm
that is specified in the "c=" tag. Any final CRLF on the
"DKIM-Signature" header field MUST NOT be included in the signature
computation.
4. Benefits
Adding a new algorithm can prove beneficial in several key ways:
a) A single canonicalization strategy can be used for both headers and body.
b) Critical headers, such as the Subject: header, can be protected from
in-transit modification that would otherwise be undectable.
c) The message body would be protected from malicious white space
rearrangements.
3. Sample Implementation
To illustrate how simple it is to implement this proposed "onewsp"
standard, you may download sample code from:
ftp://ftp.bcx.com/pub/bcx/onewsp.c
Thank you for considering this matter,
--Bryan Costales
Senior Software Architect
Goodmail Systems, Inc.
http://www.goodmailsystems.com