EKR wrote:
I believe the point Dave is trying to make is that you don't need to
deploy a huge infrastructure to deploy DKIM.
Well, in that case you could argue the same thing about S/MIME,
which can work in opportunistic (only partly secure modes).
Right. See below about weaker claims and the lack of a fully deployed
PKI. It is designed primarily to scale to the level of a domain.
DKIM does NOT require
DNSSEC.
And S/MIME doesn't require PKI.
S/MIME has its own set of problems, which I won't rehash.
Deploying DNSSEC improves the security of DKIM in the face of
DNS attacks.
In the face of attacks which we know happen....
In those places where that's important perhaps we'll see DNSSEC
deployment, then.
S 1.2.2
the basis for evaluating whether to trust the message for delivery.
I'm not sure "trust" is a useful word here.
The intent is to state that if you know who you're dealing with you can
decide how best to dispose of the message.
That's fine, but trust is a word with a complicated history.
I agree.
The owner of the domain name being used for a DKIM signature is
declaring that they are accountable for the message. This means that
their reputation is at stake.
I'm not sure I understand what reputation means in this context.
I believe it would be pedantic to define a commonly used English word.
I disagree.
1. It's a technical term in the security community, and since there's
no reputation service being proposed..
The language was plainly used. You are, however, raising two separate
issues: use of the term and whether reputation services are in scope.
They are clearly not. However, that doesn't mean that DKIM cannot be
used by such services, and it certainly doesn't mean that we must never
refer to them. This having been said, I still believe the plain
language reading connotes an obvious meaning.
2. As I've pointed out before, manual forensics about who actually
sent a message aren't really *that* difficult. Transmitting a message
at all puts your reputation on the line--to the extent that sending
spam damages your reputation.
Forensics != verification.
This claim strikes me as rather strange.... Remember that X.509 *was*
intended to work with a directory, indeed The Directory (X.500). So,
while it's certainly true that it's hard to get keys, it's not that
the guys who designed it were somehow too stupid to know about
directory systems.
I read Dave's claim is to the contrary. They presumed a directory
infrastructure that in fact has proven difficult to widely deploy to the
level of the individual.
Hmm... I don't read it that way. The beginning of 5.4 says:
Unlike all four previous IETF email security initiatives, DKIM
employs a key centric, directory based PKI as opposed to a
certificate based PKI in the style of Kohnfelder (X.509) or Zimmerman
(web of trust).
Which seems to suggest that X.509 isn't directory-based. But as I
noted, the original design certainly was....
While I could see how you could take this one sentence out of context
and view it as poorly worded, let's agree that the author does not
believe X.509 was implemented outside the notion of a directory. Let me
suggest, therefore, that you propose wording to clarify.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html