ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Charter bashing...

2005-10-12 14:56:34
The service/mechanism distinction is a good one to try maintain, though
as you say, given that we've only one real choice of mechanism its easy
enough to slip up, as I guess I did. (Whether that constitutes a "huge"
step in any direction at all is however debatable;-)

Well, anything is debatable of course. Nevertheless, a problem we've had over
and over and over again is confusion of what DKIM aims to what S/MIME or PGP
do. I trace at least some of this confusion to careless substitution of
mechanisms for services and vice versa, and some more of it to our not being
clear about what the goals of the DKIM service actually are. Given the "running
code" we have on this point I don't think a conclusion that this is the wrong
direction to be headed in is hard to reach.

So, if we were to use that opener, I guess you'd prefer something
like:

   The DKIM working group will produce standards-track RFCs specifying
   how to integrity protect mail messages via fields (incl. e.g. digital

   signatures) added to the message headers. Depending on the options
   chosen these fields can integrity protect (some) message headers as
   well as (parts of) the message body.

But, do you have a better term for the service than "integrity
protect"?

Integrity protection is indeed a service, but it isn't the service DKIM
provides. The service DKIM provides is the ability to "assert responsibility
for an email message in transit by means of a digital signature." This is how
the threats document puts it and while it is not exactly how I'd put it (I
prefer the term "accountability" to "responsibility") I'm comfortable with it.

The fact that DKIM provides some degree of integrity protection is an
unavoidable consequence of the need to prevent an attacker from
taking an assertion out of a message and applying it to a different message.
But that doesn't make it the goal of DKIM - far from it.

I note in passing that the term "integrity" appears nowhere in the threat
analysis document. Perhaps it should, if only to make it clear the goal of DKIM
_isn't_ to provide this particular service.

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