ietf-mailsig
[Top] [All Lists]

RE: nowsp considered harmful

2005-07-20 08:20:19

I think we need to have rules that are a bit more solid.

Advice on how to detect a fraud is not very reliable.

One scheme that might be effective is to require that in the case of a
MIME message the l= parameter MUST encompass the entire MIME package and
that it is an error if the MIME boundary does not appear within the
signed portion.

I think this addresses the attack described. It is also pretty clear how
the scheme would be extended to any other packaging format.

In other words if you have:

Headers: blahh
Headers: blahh
Content-Type: MIME boundary=fooo1

--- MIME Boundary fooo1 ---

Signature cannot end here

--- MIME Boundary fooo1 ---
*Signature can end here though


Obviously we have to do quite a bit of tweakage to get the scheme
complete. We need to make sure that multiparts are handled correctly.
But it is certainly do-able and is not at all likely to break existing
code.



-----Original Message-----
From: Michael Thomas [mailto:mike(_at_)mtcc(_dot_)com] 
Sent: Wednesday, July 20, 2005 10:25 AM
To: Hallam-Baker, Phillip
Cc: Tony Hansen; ietf-mailsig(_at_)imc(_dot_)org
Subject: Re: nowsp considered harmful


Hallam-Baker, Phillip wrote:
One option would be to require MIME boundaries to start immediately 
after the header if the l= is specified.

One can also delete everything appended as is recommended in 
the draft. This really has nothing to do with nowsp.

              Mike



-----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



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

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

iD8DBQFC3lAhxsSylYhzrRYRAkePAJ9iupVBb2LTdWnUSxDLo82caZqrpgCfT20W
IRfv9NS674B+ThXhrMMlfNg=
=QF0W
-----END PGP SIGNATURE-----








<Prev in Thread] Current Thread [Next in Thread>