ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] review of draft-ietf-dkim-overview-01

2006-07-11 12:23:08
Eliot Lear <lear(_at_)cisco(_dot_)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
DNSSEC. 

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.


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

-Ekr
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html