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
fact.
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
conjecture.
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
<address>".
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".
etc.
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
grim.
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.
Keith
_______________________________________________
ietf-dkim mailing list
http://dkim.org