[ietf-dkim] Re: One space proposal

[Tony Hansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<Further discussion of this should move to ietf-dkim at mipassoc.org.>

One major modification I'd make is to NOT change the CRLF in the body.
This totally avoids the spoofing problems with changing the mime
structure when l= is used.

	Tony Hansen
	tony at att.com

Bryan Costales wrote:
> 
> 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
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC80nNxsSylYhzrRYRAhT7AKC/YQ+oLKq2jFcvjyZFdJMECLPbQwCfd2mo
9ReNRfVqCtkzGBLU+AuXhvs=
=c66j
-----END PGP SIGNATURE-----