Subject: Re: [Asrg] New DKIM canonicalization to avoid broken signatures

From: Alessandro Vesely <[email-masked]>
Date: Thu, 22 Jul 2010 20:05:28 +0200

On 30/Apr/10 19:58, Murray S. Kucherawy wrote:
>>  From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
>>  We'd need to discuss the details, implement them, and test.
>>
>>  Anyone interested?
>
> I'm up for the conversation, and OpenDKIM is a decent place to exercise a well-considered alternative canonicalization scheme if the participants can reach consensus.  If something comes out of that which makes sense and works, it becomes a candidate for standardization.

This just to note that a similar approach --considering MIME entities, 
that Charles Lindsey called "a somewhat more aggressive 
canonicalization"-- was introduced about October 2006 [CL1].

One month later, Charles wrote again [CL2], giving a proof of concept 
in Perl [UNC].  Some of the WG responses may illuminate on why John 
suggested to change list for this discussion...

> But I have no illusions that any of that will be an easy trek, technically

I think we'd just need to find a suitable MIME library in C, and 
experiment so as to come out with "an Internet Draft documenting a new 
proposed canonicalization" (in Barry's words [BL]).

However, before possibly shifting to yet another list (opendkim-*), it 
may be useful to discuss whether we want to limit signatures to parts 
that won't be dropped, e.g. using l= or similar tag.  For example, 
alternative HTML text poses a difficulty, because either part can be 
used, or dropped.  How about adding a "part-hash" in each entity's header?

>   or politically.

I'd leave esoteric stuff to somebody else :-)

-- 
[CL1] http://mipassoc.org/pipermail/ietf-dkim/2006q4/006305.html
[CL2] http://mipassoc.org/pipermail/ietf-dkim/2006q4/006629.html
[UNC] http://www.cs.man.ac.uk/~chl/uncode/uncode.html
[BL] http://mipassoc.org/pipermail/ietf-dkim/2006q4/006648.html

---

From: David Nicol <[email-masked]>
Date: Thu, 22 Jul 2010 13:24:37 -0500

> However, before possibly shifting to yet another list (opendkim-*), it may
> be useful to discuss whether we want to limit signatures to parts that won't
> be dropped, e.g. using l= or similar tag.  For example, alternative HTML
> text poses a difficulty, because either part can be used, or dropped.  How
> about adding a "part-hash" in each entity's header?

There's always PGP, a paradigm where SMTP is merely the transport
layer over which the communication rides in a secure tunnel.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 23 Jul 2010 13:03:05 +0200

> layer over which the communication rides in a secure tunnel.

Apparently, PGP suffers some of the same defects of that Charles 
outlined for S/MIME in [CL3].  In addition, client support is not 
widespread.

At any rate, it seems that DKIM has to sign the contents as a means to 
avoid replay attacks.  Therefore, even if we reused PGP or S/MIME, 
we'd need to specify how to integrate them with DKIM, so that failure 
to verify any signed part implies failure of the DKIM verification too.

Let me make the "part-hash" idea explicit.  I'm not actually proposing 
such kind of solution, but the fact that it lays somewhere between RFC 
1847 and the DKIM approach, may elicit further insight.  Consider this:

  DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/postponed;
   d=example.org; s=selector; t=1279882516;
   h=Message-ID:Date:From:Mime-Version:To:Subject;
   b=UQbHb+18Dn8jSwgoVl1W38GUohv+Tll4Z/8eulbg0iQG0OUk7
    uATrt7Zbm3ubwPlya2vMLtNYYYvLs0rTidbZijQL8qG9QxVsBk
    Ol0WxWgbTJ2A/HSouU1RoVpP5LdULDkEs5HnV7PV35fcggZ7Vk
    1VNC7T+yDSEkuhQw=
  Received: from [192.0.2.0] (sender.example [192.0.2.0])
   (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1)
   by msa.example.org with ESMTPSA; Fri, 23 Jul 2010 12:55:16 +0200
   id 00000000005DC02B.000000004C4961E9.00007D16
  Message-ID: <[email-masked]>
  Date: Fri, 23 Jul 2010 12:55:16 +0200
  From: User <[email-masked]>
  Mime-Version: 1.0 (do we sign this comment?)
  Content-Type: multipart/mixed; boundary="=boundary" (not signed)
  To: Someone Else <[email-masked]>
  Subject: test

  This is MIME-formatted message.  It is useless to sign this preamble,
  as email software that supports MIME-formatted messages may alter it.

  --=boundary
  Content-Type: text/plain; charset=us-ascii; format=flowed
  Content-Transfer-Encoding: 8bit
  DKIM-Signature: c=mellowed;
   bh=f5Ntex6CQc9yQ5G0sHQSlHe2NtZLLBy1fomussAxaE0=;
   b=UQbHb+18Dn8jSwgoVl1W38GUohv+Tll4Z/8eulbg0iQG0OUk7
    uATrt7Zbm3ubwPlya2vMLtNYYYvLs0rTidbZijQL8qG9QxVsBk
    Ol0WxWgbTJ2A/HSouU1RoVpP5LdULDkEs5HnV7PV35fcggZ7Vk
    1VNC7T+yDSEkuhQw=

  The body of this MIME entity is signed on its own, using 8bit.

  The "master" signature supplies any parameters, such as v=, a=, d=,
  s=, t=, that are not overridden by the entity-signature.  The master
  signature signs headers only.  However, Content-* headers should not
  be signed (that also avoids format=flowed to format="flowed" kind of
  changes).

  Entity headers are not signed, only their body is.  Any encoding is
  undone, recovering the original content, possibly binary.  For plain
  text, some punctuation is replaced by spaces --in particular the
  greater-than signs ">"-- and multiple whitespace is replaced by a
  single space.  Recall it only has to be robust enough to deter
  from replaying.

  --=boundary--

  Any epilogue is also not signed.

Would such signatures survive even when attachments are dropped?

Could such signatures be (partially) verified by software not 
implementing the "postponed" and "mellowed" canonicalizations?

-- 
[CL3] http://mipassoc.org/pipermail/ietf-dkim/2006q4/006640.html