ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Features that could be reconsidered as part of the bis process

2009-05-20 18:46:28

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

<Prev in Thread] Current Thread [Next in Thread>