ietf-dkim
[Top] [All Lists]

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

2005-08-16 16:13:53
On August 16, 2005 at 14:50, Michael Thomas wrote:

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?

If I understand correctly, DKIM is used to provide a cryptographically
verifiable audit trail.  The parts of the messages that are signed
depend on the role the signer plays during the message life cycle.
Some may sign the content while some may only sign trace information
(like Received fields).

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.

But the semantics of multiple signatures is punted in the DKIM
draft and clearly distinguishing different signature header fields
is problematic.  If a signer wants to include an existing signature
field, signature fields should have a clear identification capability
so a verifier can easily determine each field when multiple exist.

 > 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.

I am guessing here that the envelope address can be included in
the signature.  This allows a binding between the envelope data
and the message data.  May be useful in replay detection and
provides clear indication of what is presented in the envelope
vs the data (for forensic and auditing purposes).

(This is tricky but I think it's doable.  You probably end up with a
different set of field names every time you submit a message, e.g.
submission-0:, submission-1: in order to finesse problems with
duplicate fields and reordering, but that's cool because it lets
subsequent submissions sign the fields from earlier submissions.)

This is possible too, I think. PHB suggested using a numbering
scheme, I think, which would probably be easier to untangle.

Not sure if this a criticism or an agreement.

For my part, I think that the From address is about the only
thing that that anybody pays regular attention to,

Not if it is spam.  Spam may have changed how people interpret From.
The only time From is relied upon is if the receipient sees that the
content of the message is matches with what they expect from From.

MUAs prominent displaying of From has affected how people view it,
rightly or wrongly.  I'm unsure this perception can be changed.
Any change would require MUA modifications.

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.

I think the point that different people have different uses for
email is important.  If email is "dulled" to what the majority
consider email to be, then email will be dead.

Side comment: It is worth noting that more younger people are moving
to instant message style services for communication over email (email
is considered to be for "older" people).  Email should not become a
poor man's IM.  It has certain semantics (that many do not utilize,
but others do) that are important.

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