[ietf-dkim] Not exactly not a threat analysis
moore at cs.utk.edu
Tue Aug 16 15:53:31 PDT 2005
> > I'm still thinking about it. Part of the answer, I think, is to have
> > DKIM separate signing of the _content_ (presumably, by the author),
> > from signing of the _submission_ (by the submitting party). Each time
> > a message were forwarded or resent, this would be a subsequent
> > submission which could also be signed without discarding records of
> > previous submissions.
> I'm not sure I understand what you mean by content and
> the submission. Are you talking about parts of the message
> or the actors involved? Or something else?
Content = what's in the message.
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"
> > So the headers of a message could contain
> > several signed submission records detailing the entire submission
> > history of that message. Each signed submission would have its own
> > hash, its own list of headers, etc.
> DKIM has the ability to do this now via multiple signatures
> in the same message. My implementation allows for it, in
IIRC DKIM can't sign envelope fields, and it doesn't clearly
distinguish between author and sender roles.
> > Submission records also need to
> > validate envelope recipient addresses.
> I don't understand what this means. About the only thing
> that I can think of that "validates" a RCPT TO is the
> next hop not bouncing it outright.
sorry, I phrased that poorly. I hope the above description is clearer.
> > It would then make sense for an MUA or filter to derive identites
> > like "initially-submitted-by" and "last-submitted-by" from the
> > authenticated submission information.
> Would this pass the My Mother test? I'm fairly skeptical that
> the human factors people would be very keen on loading up
> a bunch of new identities for people to keep track of. In
> fact, I doubt that 1 person in 10 could give you a passable
> definition of what Sender is, and that's currently displayed
> fairly often.
In order to even begin to answer that question with any confidence,
we'd first need to do a case analysis, and then we'd need to try to
design user interfaces to handle those cases, and then we'd need to
subject those user interfaces to testing by randomly-selected users.
We might want to measure existing email users separately from those who
don't currently use email - because in the long term the latter group
might be a better predictor than a group that is conditioned by current
MUAs and protocols. And until we do this - this entire discussion is
But yes, I think it's feasible to design user interfaces that would
make these distinctions clear to your (or my) mother. I certainly
don't expect users to understand and distinguish the subtle differences
between From, Sender, signer, forwarder, etc. when presented in that
way. But I do think that a future MUA could reasonably do something
like the following when presenting received mail:
a. (default) Message is authored (From) by A, signed by A, and
submitted by A to be sent to your mother. Just show the From field and
perhaps some icon showing that the message was signed.
b. Message was authored by A, signed by A, but initially submitted to
some other address and later forwarded to your mother. Show the From
field but also show a highlighted alert that says "this message was not
sent to you by the author of the message, but was forwarded to you by
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".
Once I do the case analysis I suspect I'll find that there are several
cases that can be grouped together.
But at any rate, I don't think we serve the interests of the user
community by either crippling the mail system or by making DKIM so
simplistic that it doesn't accurately represent what actually happened
to the message.
> For my part, I think that the From address is about the only
> thing that that anybody pays regular attention to, and if
> we're going to provide any new assurances it needs to
> align with what they know, or at least think they know.
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.
> Ok, I just did the SO test in lieu of My Mother and upon
> looking at a Sender for this list, sez he "is that your
> new thingy?" (meaning, DKIM). Asked if ListId meant anything
> to him, "does it have something to do with the Cc?"... so,
> I really wouldn't be too hopeful about any expectation that
> anybody's going to understand much beyond color codes,
> cutsey icons, or very simple text next to the From address.
And again, I certainly don't expect users to sort out this stuff by
looking at message headers. (they couldn't verify the signatures by
looking at them anyway). So yes, cutsey icons and simple text
displayed above the message on a colored background is very much what I
have in mind.
> > 1) at the time multipart/signed was defined there were still a lot of
> > people using legacy MUAs that didn't handle multiparts properly, and
> > certainly didn't handle multipart/signed properly. So you didn't want
> > to enable multipart/signed on all outgoing messages.
> According to what I've heard, the situation is still pretty
> >>From the big picture view, the number of MUAs that will get tweaked to
> > display this information - as opposed to simply being upgraded - is
> > probably insignificant. But being able to tweak existing MUAs is
> > useful to permit experimentation by early adopters.
> Possibly -- I'd be happy if this were incorporated quickly. But
> we didn't want to have to insist on it happening. FWIW, we've been
> looking internally as to how to show users that "this piece of mail
> really came `from' Cisco" from phishing attacks, and the resulting
> case overload for IT of people reporting our spam^H^H^H^Hcompany
> internal mail as possible phishing. There are a variety of ways we can
> go about presenting this now. I'll note that somebody has a DK
> Thunderbird plugin now which presumably does something interesting to
> the result (I've been meaning to dissect it, but haven't got around
> to it.)
I'll have to look at it. Maybe we should all try to eat our own
dogfood and use DKIM as much as possible on this list.
More information about the ietf-dkim