ietf-dkim
[Top] [All Lists]

Re: Fwd: Re: [ietf-dkim] Introducing myself

2006-12-06 10:10:49

So it looks to me like you're suggesting a new c14n algorithm for
the WG to consider.

If so, I think the proper course would be to write that up as a
draft-lindsey-dkim-foo and then we can see if we like it or not.
(While having the perl code is great, its not necessarily the
easiest thing for everyone to analyse.)

And we do have pluggability in base for c14n, so that if you're
right, and this new c14n produces significantly less brittle
signatures, then your new c14n algorithm would probably get
adopted fairly quickly in any case.

That suggests not trying to replace what we have in base, but
rather proposing your new scheme as an alternate. In the meantime,
we should proceed with getting more deployment experience based
on the current approach.

To me, that seems like a better approach than trying to make such
a significant last minute change, which I would have a problem with
in any case, mainly on the grounds that we'd need a reasonable time
to do a security analysis of any new c14n proposal.

Does that sound like a way forward?

Stephen.

Charles Lindsey wrote:
On Mon, 06 Nov 2006 10:47:45 -0000, Charles Lindsey <chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk> wrote:

On Sat, 04 Nov 2006 02:03:38 -0000, John Levine <johnl(_at_)iecc(_dot_)com> 
wrote:

That was quite some time ago, so to refresh your memories, I had been claiming that DKIM-base would fail to verify if some message had its Content-Transfer-Encoding changed en route, and that it proposed to get around this by saying that all messages SHOULD be sent as 7bit, or encoded into 7bit. In these days when 8BITMIME is now almost universally supported and widely used (with BINARYMIME coming along as well), that seemed to be a very backward step. So I proposed a canonicalization that would reverse all those encodings before hashing.

You can sign whatever you want, but if the message is 7bit, your
signature is more likely to survive transit to the verifier.

But of course I don't want them to be "likely to survive". I want a system that is robust enough that they "always survive".

DKIM doesn't understand MIME.  If DKIM signers and verifiers had to
unpack MIME parts they would be orders of magnitude more complicated.
In practice, I think that nearly everyone uses the simple body canon
anyway.

Not at all. Going through the MIME structure of a message body and undoing
all Q-P or Bas64 encodings is fairly straightforward, and if you hash and
sign the result of doing that, then it is guaranteed to pass straight
through all those systems which (quite legitimately under RFC 1652)
re-encode stuff en route, without breaking the signature. I shall try to
write a demonstration implementation in the next day or so, and it
certainly won't be "orders of magnitude more complicated".

So it was an issue of whether such a canonicalization really would be "orders of magnitude more complicated". Anyway, I have been working off and on on this since then, and I have written a demonstration implementation, as promised, of what it would take, which you can find at <http://www.cs.man.ac.uk/~chl/uncode/uncode.html>.

It is less that 140 lines of Perl (excluding comments and empty lines). Hardly any "orders of magnitude" in evidence there.

--Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according tohttp://mipassoc.org/dkim/ietf-list-rules.html


_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html