[ietf-dkim] review of draft-ietf-dkim-overview-01
ekr at networkresonance.com
Tue Jul 11 12:20:09 PDT 2006
Eliot Lear <lear at cisco.com> writes:
> Hi Eric,
> I would generally agree with you about the enthusiasm of the document.
> This is probably a good place for it, so long as it's accurate. I would
> quibble with you on one point:
>> o there is no dependency on the deployment of any new Internet
>> protocols or services for public key distribution or revocation,
>> I think this is a bit misleading. DKIM depends partly on DNSSEC
>> for security, and that is not yet widely deployed.
> 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).
> DKIM does NOT require
And S/MIME doesn't require PKI.
> Deploying DNSSEC improves the security of DKIM in the face of
> DNS attacks.
In the face of attacks which we know happen....
>> 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.
>> 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.
1. It's a technical term in the security community, and since there's
no reputation service being proposed..
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.
>> 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....
More information about the ietf-dkim