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