Subject: Re: [Asrg] A MIME-safe DKIM canonicalization idea

From: Alessandro Vesely <[email-masked]>
Date: Sun, 25 Jul 2010 21:10:04 +0200

Hi Murray,
> Just brainstorming here...

Yeah, we need some...  However, I guess the hosting-list field has 
been stormed away as a side-effect :-)  I cc ASRG --you probably 
meant that one.

> What about a new body canonicalization called "simple-mime" (and maybe "relaxed-mime", with the obvious difference) that does the following:
> 
> - adds to the signature a list of MIME types that defines the list of parts that got signed and in which order

This resembles using "parallel arrays" vs arrays of structures.  A 
couple of pros that I can see are

* it may have higher chances to be left alone in case the MIME
   structure is rewritten, and

* it is easier to insert a single header field, as the signing
   application doesn't have to coordinate with the library for each
   entity.

On the cons side, there are the generic disadvantages mentioned in 
http://en.wikipedia.org/wiki/Parallel_array (obscurity being the 
most relevant, IMHO.)

> - all parts are decoded prior to signing/verifying

This is necessary, as there are multiple ways to encode the same 
data, e.g. varying the line length in base64.

> For example, given a message like so:
> 
> 	From: whatever
> 	To: whatever
> 	Subject: whatever
> 	Date: whatever
> 	MIME-Version: 1.0
> 	Conent-Type: multipart/mixed; boundary="foo"
> 
> 	Preamble text
> 
> 	--foo
> 
> 	La la la
> 
> 	--foo
> 	Content-Type: application/octet-stream
> 	Content-Transfer-Encoding: base64
> 
> 	Base64-stuff-here
> 
> 	--foo
> 
> 	This text should not be signed
> 
> 	--foo--
> 
> 	Postamble text
> 
> In this example you would generate a DKIM signature in the usual way, except:
> 
> - the signature will contain "c=relaxed/simple-mime"
> - the binary part will be decoded to 8-bit before being passed to the hash
> - preamble and postamble text is ignored
> 
> Are there cases that need to be addressed that this wouldn't cover?

If an attachment is dropped --or replaced with some boilerplate 
about the types of allowed attachments-- it may still be useful to 
verify the integrity of the rest of the message.

I'm aware that some software process text/html parts --or 
alternatives thereof-- in peculiar ways.  I've spent a few time 
googling for message transformation practices, e.g. for gatewaying 
mail to netnews, but failed to find a clean list of "acceptable" 
changes that a message may undergo in transit.  IMHO, we'd need such 
kind of list in order to decide what to cover.  (Will the DKIM base 
interoperability report include anything like that, possibly?)

> If there's a need to allow addition of appended text/plain parts, you could add an "m=" tag that somehow encodes the list of MIME parts that are part of the signature, such as this based on the above:
> 
> m=1/multipart/mixed:2/text/plain:2/application/octet-stream:2/text/plain
>
> This indicates which parts got signed and what the nesting looks like, preventing some amount of reordering (though in the above you could swap the text/plain parts).

I've seen using tags like "1.2" to refer to nested entities; e.g. 
http://www.courier-mta.org/reformime.html

I note that you said "add a tag".  In facts, like many specs, RFC 
4871 says that "Unrecognized tags MUST be ignored."  That way, tags 
can be added without breaking compatibility with exiting software. 
However, the same is not true for canonicalizations: "c=relaxed/ 
simple-mime" cannot pass existing verifiers.  Instead, with 
something like "c=relaxed; l=0; m=...", we might be able to get a 
somewhat more compatible MIME-safe scheme.  Would such kind of 
(possibly temporary) hack be worth its nuisance value?

---

From: Steve Atkins <[email-masked]>
Date: Sun, 25 Jul 2010 14:16:35 -0700

On Jul 25, 2010, at 12:10 PM, Alessandro Vesely wrote:

> Yeah, we need some...  However, I guess the hosting-list field has been stormed away as a side-effect :-)  I cc ASRG --you probably meant that one.
> 

> If an attachment is dropped --or replaced with some boilerplate about the types of allowed attachments-- it may still be useful to verify the integrity of the rest of the message.

The point of DKIM is not to verify the integrity of the message. That's just a side-effect of protection against replay attacks.

We sign the body content in DKIM just to avoid replay attacks - where an attacker takes a validly signed message and replaces the content with their own or adds to the existing content without invalidating the signature.

If you allow any modification of the MIME structure - such as replacing an attachment with some boilerplate -  in a way that allows an attacker to add to or modify the content that is accessible to the recipient without invalidating the DKIM signature then you're opening up that attack vector.

Murray is talking about a canonicalization that's robust against encoding changes, which is a very different thing.

Cheers,
  Steve