Keith Moore wrote:
I certainly agree that DKIM appears to have lower barriers to
deployment than some of its predecessors (e.g. S/MIME), and I also
think that there's more of a perceived need for something like DKIM
than there was for its predecessors...if S/MIME were being promoted as
a new thing today, it might be more successful.
I'm not sure that DKIM lowers the barriers enough to enable the
"network effect", but I think it's a step in the right direction if it
can lower the deployment barriers AND be made to provide the right
functionality. (I don't think it does the latter yet)
Ok, tell us what the right functionality is.
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. 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. Submission records also need to
validate envelope recipient addresses.
(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.)
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.
MUAs could use this information to display alerts to recipients, to
let them know of unusual circumstances e.g.
- (pick two or more of) { author, signer, initial-sender } are different
- message was resent to <your-address> by <last-sender-address>
as well as errors (e.g. signature validation failed)
But this is a bit premature - as right now we need to be thinking about
necessary functionality and threat model.
but I think goal #4 is unrealistic or misstated. DKIM should be
relatively non-hostile to legacy MUAs and MTAs (as compared to
multipart/security based solutions) but MUAs and also some
MTAs will need to be upgraded to significantly benefit from
DKIM.
Yes, of course some MTA's will need to be upgraded, what
I meant is that you can pick and choose them selectively
which makes the chore easier.
Definitely. And incremental deployment is extremely important,
though one could argue that multipart/signed was also incrementally
deployable. I see two significant differences between those and DKIM:
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.
2) By leveraging DNS as a way to verify sigs, DKIM finesses the problem
where the recipient's MUA complains because it doesn't recognize or
trust the author's CA even though the signature is valid.
As for MUA's, I agree that
the maximal benefit will arrive when they can take advantage
of DKIM, but I don't think it's strictly necessary -- I can
today devise a filter in almost all MUA's which blats something
onto the screen so I can tell whether the message verified or
not. Maybe you consider this "modification", but I meant it in
the sense of having to wait for a design/release/uptake cycle,
as well as the sense of "no flag day required".
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.
Keith
_______________________________________________
ietf-dkim mailing list
http://dkim.org