On May 20, 2009, at 2:53 PM, Michael Thomas wrote: > Steve Atkins wrote: >> On May 20, 2009, at 2:17 PM, Michael Thomas wrote: >>> Steve Atkins wrote: >>>> Why would you want to sign email as something you vouched for, >>>> while still enabling anyone to replace the content of the email >>>> with something else without invalidating that signature? >>> You can't replace it; you can only append to it. >> That's likely wrong, depending on the details of the l= usage. > > No I'm not. > >> Firstly, one expressed use case for l= is "l=0" - in other words, >> don't >> sign any of the body. In that case I can put any body content in >> there >> I like, and it'll still be validly signed. > > That's still appending. > > >> Another use case is to use l= to sign a text part of an email, but >> not >> to sign an attachment. > > That's still appending.
>> Another use case is to set l= to the entire length of the email as >> sent. > > That's still appending. It's only appending if you don't care about the email itself, just the protocol. Remember that we're considering the content of the message as displayed to the end user here, not the traffic on the wire. If I can control the content of the message as it's displayed to the recipient, then the fact that I only have limited control as to the changes I can make to the bytes on the wire is pretty much irrelevant. > DKIM only talks about taking responsibility, and only for the parts > that > are signed. How an evaluator deals with the unsigned parts of a > message > is outside of the scope of DKIM. But when we're talking about the benefits of something you can't constraint your discussion to just the details of the protocol - how it will be used, and how it will be attacked, in use are the core of what's important, and definitely within the scope of a discussion about whether a feature provides a benefit or not. > > (though the supposed benefit it offers is not clear) > > You forgot "to me". Not really. I don't think the supposed benefit clear to anyone, including those who are interested in including the feature. There have been a couple of concrete examples suggested, but they mostly don't actually make any sense when you dig into the details. There are a few, exceptional cases where using l= to preserve a DKIM signature via a forwarder that would otherwise break it would actually work (a sender choosing to use l= to sign the entire length of their message sending plain text mail to a mailing list that does not modify the body of the message other than appending a footer and does not modify the signed headers - no From, Subject, Reply-To changes - for instance). But those few cases are so rare or unlikely as to be pretty much theoretical. You can find more likely cases by reducing what you sign (don't sign the Subject, don't sign the From:, don't sign Reply-To: and so on), but once you start doing that then you're really opening yourself up to replay attacks. (Even if you don't care about replay attacks yourself, they mean that a DKIM signature - or at least one using l= - becomes pretty much meaningless to the None of the mailing lists I'm currently subscribed to could take advantage of l= to preserve a DKIM signature in general (the only ones that append a footer also rewrite the subject to add a mailing list tag or add a Reply-To) - though some of them would support it in the case of replies to email from the list. None of the email I see that has advertising appended to it has had the advertising appended after it has been (or would have been signed). I've no doubt someone can find a real-world example but unless it's reasonably common for l= to be useful- rather than vanishingly rare - it doesn't seem enough to count as a significant benefit, let alone one that's big enough to counterbalance the security holes it opens. If there's a use case I've missed, I'm all ears. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
