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

[EKR]

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
> 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