Re: [ietf-dkim] Not exactly not a threat analysis

> > Signed content is a verifiable statement that says "Alice wrote this
> > message" or "Alice authorized this message".
> > Submission = the act of sending a message to specific recipients.
> > Signed submission is a verifiable statement that says "I sent this
> > message to recipients Alice, Bob, and Carol"
> Why is it important to know who the recipients were?
a) so that if a recipient Carol complains that she was spammed by  
Alice, it is possible to expect Carol to produce evidence that this  
is so to avoid harming Alice's reputation.  (unless they have a way  
to expect such evidence, reputation servers are too easily fooled)
b) so that if Alice sends an advertisement to Bob, and Bob forwards  
it to a large number of other addresses, it is clear that Bob, not  
Alice is responsible for the messages forwarded by Bob.
c) (maybe) so if Alice wants to send advertising to Bob with the  
promise that she will pay Bob $1 for reading it, Bob cannot  
distribute the message to N of his friends so that they'll each get  
$1 also.
> > IIRC DKIM can't sign envelope fields, and it doesn't clearly
> > distinguish between author and sender roles.
> If it were important, it could easily be added. I don't
> understand why it's important. And I don't understand
> what is gained by separating roles.
lots of people have been wanting protection against replay attacks

> > c. Message was authored by A but signed by someone else.  Show the  
> > From
> > field but also show a highlighted alert that says "This message  
> > claims
> > to be written by A but was signed by B".
> You just lost My Mother, I think. Well, at least you lost
> me because I have no idea how I ought to behave in its
> presense.
it's worth exploring, I think.

a) What would you do if you got a snail mail that purported to be  
from George Bush but for which the signature at the bottom read Rush  
Limbaugh?
b) What would you do if you got a snail mail that purported to be  
from president(_at_)whitehouse(_dot_)gov but for which the signature at the  
bottom read george(_dot_)bush(_at_)whitehouse(_dot_)gov?
i.e. is it ever reasonable for the From address to be a "role"  
address and the actual signature be by an individual?  and if it is,  
is the signature meaningful?  would it be meaningful if you had an  
established relationship with that person and knew that was his email  
address?  what if you didn't?
would it make more sense to say that the "role" address should sign  
the message?  what about when different people are authorized to fill  
a role?  wouldn't you want to know specifically who signed it?
would it make sense to forbid "role" addresses in From fields?  OTOH,  
they're useful.
c) What would you do if you got a snail mail that was authored by  
Tom, Dick, and Harry but was signed only by Harry?
> > You are assuming current users, current MUAs, current protocols  
> > without
> > DKIM, current expectations based on these. I'm assuming that new  
> > users
> > and new MUAs will eventually be significant, and that they'll be more
> > sophisticated.  Users do adapt, though perhaps they do so slowly.  A
> > few years ago users would blindly enable cookies in web browsers and
> > forget about them, now significant numbers of users are periodically
> > deleting them.  Many users change their email addresses  
> > periodically so
> > that they'll get less spam and maintain separate accounts for casual
> > correspondence between acquaintances, serious correspondence between
> > close friends, etc. - changing the casual address more often than the
> > others.  Many users have figured out that when sending a message to
> > large numbers of recipients, it's a good idea to use Bcc so that the
> > replies don't go to everyone.  etc.
> You misunderstand: I obviously believe that they have some
> possibility of changing their behavior based upon better
> technology, but I don't believe that it can be very complicated.
> We have to be very, very wary of the law of unintended
> consequences as well cognizant as the principle of least surprise.
I think things need to be as easy to understand as we can make them,  
but not so simple that it misrepresents reality when there's an  
important difference between cases.  I want to see how understandable  
these things can be made rather than assume that they cannot be made  
understandable.
note that one potential way to make things understandable is to find  
a way to distinguish clearly bogus cases from marginal cases and make  
sure that your mother never sees the clearly bogus cases unless she  
really wants to.
> For example, I'll bet a good amount that Mark/Miles' folks either
> did a bunch of testing or never even contemplated putting up
> a neutral/negative flag ("Y! has not been able to verify if
> this domain sent this message" or somesuch) because of the
> potential for help desk meltdown. That might change in the
> future of course, but the point is that there's a large
> installed base out there so we have to be very careful.
perhaps, but I don't think Y! mail serves a representative sample of  
users.  a large sample, yes, but their market doesn't seem to be  
business users.  or at least, that's my impression.
> Well, DKIM doesn't make it through this list unless you use l=
> and z=. :)
given that this list behaves pretty typically, I'd say this is  
potentially a major flaw.
Keith

_______________________________________________
ietf-dkim mailing list
http://dkim.org