Tony Hansen wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Yes, that's an example of how we could change the definition of l= to
make it safer. (It also starts walking down the path of making DKIM
MIME-aware.)
Not really. If you view l= as a protocol/canonicalization element,
it just tells you where that signnature's material ends, and
any potentially unsigned material begins. That in turn can be
taken as input to a set of hueristics (aka spam filters) which
consider what the whole message is trying to achieve. Those
filters do already crack the mime content so we're not really
introducing anything new on the mime front. We will be introducing
some potentially very useful new input to those filters, especially
when you mate it with future reputation work.
It should be mentioned that content after the canonical set of
bytes with l= need not be "unsigned". A mailing list, for example,
should resign the message including their added trailers. The
combination of the two signatures, again, provides input to the
external filters. It may end up being that unsigned content is
*always* deleted -- thus giving no use to this attack. That
would be fine by me.
Mike
Tony Hansen
tony(_at_)att(_dot_)com
Hallam-Baker, Phillip wrote:
One option would be to require MIME boundaries to start immediately
after the header if the l= is specified.
-----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Tony Hansen
Sent: Wednesday, July 20, 2005 9:23 AM
Cc: ietf-mailsig(_at_)imc(_dot_)org
Subject: Re: nowsp considered harmful
The subject line is misleading. This is really an indictment
against the
*combination* of l= and nowsp, not nowsp per se or l= per se.
I'm not sure whether it's nowsp that needs to be changed, l=
that needs to be changed, or whether we just need to disallow
the combination.
Tony Hansen
tony(_at_)att(_dot_)com
Thomas Roessler wrote:
nowsp, when combined with the length parameter, can enable
attackers
to completely replace the e-mail content displayed by mail user
agents, without invalidating the DKIM signature.
Consider a message that has a multipart/mixed as its top level body
part, with boundary parameter "foobar", and which is fully signed,
with a length parameter (l=) that ensures that the
signature includes
the final delimiter line.
The body of this message could, for example, look like this:
|--foobar
|Content-Type: text/plain
|
|nowsp, when combined with the length parameter, ...
|
|--foobar--
Anything before the initial "--foobar" is ignored, as is anything
after the final "--foobar--".
nowsp means that we can freely move line breaks or space characters
without invalidating the signature. Let's do that.
|--foo
|barContent-Type: text/plain
|nowsp, when combined with the length parameter, ...
|
|--foo
|bar--
This message is, for all intents and purposes, the same as the
original one -- at least, as far as DKIM is concerned. In terms of
MIME, we have just removed any occurence of multipart delimiters.
Use of the length parameter means that the attacker can freely add
content.
Let's do that now:
|--foo
|barContent-Type: text/plain
|nowsp, when combined with the length parameter, ...
|
|--foo
|bar--
--> +
+--foobar
+Content-Type: text/plain
+
+nowsp, when combined with the length parameter, solves
+all e-mail security problems.
+
+--foobar--
The material before the "-->" is called the preamble of the
multipart,
and MUST be ignored according to RFC 2046. It's the signed
material.
Everything behind the "-->" is what's really displayed.
It's what the
attacker added.
This problem should be solved on the level of the canonicalization
mechanism, not on the level of maybe displaying appended material
differently.
Note that, even without the length parameter, messages can be
corrupted heavily (to the extent of not being displayed at all) by
moving around whitespace, and still be displayed as signed. That
could open up the way for what may be an attack against DKIM
deployment: What happens when people start receiving tons of
meaningless e-mails, all of which are DKIM-signed by their
bank? Also,
will they continue to take the mecahnism seriously when
they get tons
of messages, signed by their bank, with all the content colored
"insecure"?
The lesson here is that it's not enough to think of the
semantics of
an e-mail body in terms of a human being staring at garbled
text/plain: Rather, whatever canonicalization method is going to be
used by DKIM ought to protect semantics of full MIME parts,
including
multipart delimiter lines and individual bodies' headers.
Everything else (including the "we don't care about bodies'
semantics,
this is header signing" school of thought) is a recipe for
more issues
like the one described above.
Regards,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC3l5NxsSylYhzrRYRAsKUAJwPfPcgCCeUxKTEHsDPJORsQNda/QCgxRjT
7Fc7KgwlHGW3GuUAwhcIumA=
=3Wry
-----END PGP SIGNATURE-----