[ietf-dkim] New canonicalizations
steve at wordtothewise.com
Mon May 30 09:14:26 PDT 2011
On May 29, 2011, at 9:04 PM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Alessandro Vesely
>> Sent: Saturday, May 28, 2011 9:29 AM
>> To: ietf-dkim at mipassoc.org
>> Subject: Re: [ietf-dkim] New canonicalizations
>> On 27/May/11 19:16, Murray S. Kucherawy wrote:
>>> I'm all for including experimental code in future releases of our
>>> stuff, especially if it's an experiment other implementations are
>>> trying. But I need to see a spec first, or enough detail that I
>>> could write one.
>> For the body, I brought some ideas. For MIME header fields,
>> punctuation and boundaries need to be omitted as well. For other
>> header fields, including the DKIM-Signature, it is probably enough to
>> remove just any white space.
>>  http://mipassoc.org/pipermail/ietf-dkim/2011q2/016692.html
>> IMHO, the "hard parts" of the code are (i) selecting a MIME parser,
>> and (ii) finding a good way to structure experimental C14Ns and handle
>> double (triple?) signatures in the existing code.
> One of the elegant things about the current canonicalizations is that they can stream. I think a system that's MIME-aware can too, but possibly not, and in any case having to teach a DKIM implementation about MIME will make it a lot more complicated and expensive. If we have to go down that road, I think working on DOSETA and MIMEAUTH is the way to go.
Streaming MIME parsers are possible, but they're not simple. Also, MIME is more complex than most people think it is, and even coming up with a canonicalization specification that is both MIME aware and does what the author intended is likely to be quite difficult.
> If we want the lower-hanging fruits, we might take the list of things MLMs like to do to messages and find ways to canonicalize those. Fortunately, we made a list of the common ones in the MLM document.
Even that seems to be adding complexity simply for the sake of adding complexity, rather than because there's an obvious benefit.
The most obvious thing that MLMs do that invalidate signatures are 1. append content to the body and 2. prepend content to the subject line. Any approach that allows me to replay messages while making those changes seems to open the door to abuse.
More information about the ietf-dkim