[ietf-dkim] Re: Forgery complexities

[Dave Crocker]

>> DKIM is an authentication technique.  It authenticate an identity.
> 
> While that is a true statement, this new identity is independent of  
> headers normally considered to be related to forgery.  Falsifying the  
> originator (author) of the message has nothing to do with the  validity 
> of a DKIM signature.

"normally considered to be related to forgery".

1. If the signer chooses to include those headers into the hash, then DKIM
provides a degree of protection against their being forged after signing.

2. You appear to be focusing on a particular kind of forgery exclusively, namely
the unauthorized use of rfc2822.From addresses by the entity doing the signing.
  Since the DKIM base does not attempt to protect against it, there is no
surprise (or problem) that it does not protect against it.  The protection
against such forgery is a delightful and productive goal, but it is not one
attempted in DKIM base.

3. DKIM SSP provides certain protections against rfc2822.From forgery, along the
lines of what you appear to be concerned about, but again, the attempted
protection is extremely constrained, so there is no surprise that it does not do
more.

All of this seems to suggest that you are concerned that DKIM is "failing" to
perform a task that it has not set out to perform.  This, in turn, suggests that
you want to pursue a different activity.


>> Authentication is not needed, unless one is worried about invalid  
>> uses of identities.  I think that it is reasonable to call that  
>> "forgery".
> 
> Adding an unseen identity within a message, and being able to verify  
> this unseen identity, does not directly deal with the current forgery  
> problem. 

"unseen identity"? I gather you mean that it is not guaranteed to be presented
to the recipient end-user.  Indeed, presentation of validation information to
the recipient end-user is not a goal of DKIM, so it is not a surprise that it
does not do it.

"The current forgery problem".  Forgive me, but I am under the impression that
there is an array of forgery problems.  Which one(s) do you mean and what is the
basis for believing that DKIM is attempting to solve it(them)?


> DKIM allows the inclusion of a signature.  The validity of the  
> signature makes no statement beyond having accepted and subsequently  
> transmitted the message.  DKIM may offer no assurances related to any  
> message content beyond the signature.

I was under the impression that SSP attempts more than that.


>> Ensuring that the received headers are the headers that were sent  
>> does not address the problem of forgery?
> 
> The signature simply indicates this was the message sent.  It makes  no 
> claims regarding any other content. 

You might want to review the nature of data integrity protection afforded by
signing a hash of the message.

  Perhaps some signers confirm
> content in some manner, but this does not provide the recipient any  
> means for concluding headers indicating the originator are valid.  

So it is probably a good thing that the DKIM base does not claim that it does.


>> The fact that DKIM provides a digital signature based on a hash of  
>> the message headers means that, in fact, it is ensuring that any  
>> modification to the headers, after the message is sent, will be  
>> detected.  Hence, they are authenticated... With respect to the  
>> identity doing the signing.
...
>      While indeed the signature may encompass headers  and body 
> content, this makes no assurance any content is valid, or  that any 
> content is being assured by the signing domain. 

1. "Valid" is a rather broad concept.  Are you suggesting that some sort of
alternative signing would mean that my sending you a note, with such a
signature, will contain a "valid" promise to send you money?

2. DKIM specifies what it validates with respect to the content.  That is all
any specification can reasonably do.  It appears that your concern is that DKIM
does not perform some other sorts of validations, which in fact it does not
claim to do.




>>> - Establish accountable domain-specific opaque identifier.
>> what does domain-specific "opaque" identifier mean?  Opaque to who?  
>> Compared to what? >
>
> The only practical solution I see for addressing replay-abuse issues  
> and to support effective techniques that detect forgery would be for  
> the signing domain to add their own opaque identifier with the  
> signature that is either sequential or related to the access  account.  
> Unlike a mailbox-address, this opaque identifier could be  assumed 
> unique for the the signing domain.  The term opaque means  that the 
> interpretation of this identifier is only understood by the  signing 
> domain.
> 
> The opaque identifier should provide the requisite anonymity (as  
> opposed to the i=).  An opaque identifier would still permit a high  
> granularity well beyond a mailbox-domain.  It should be obvious  
> mailbox-domain authorization is limited to the granularity of the  
> mailbox-domain.  If this domain is dereferenced, or open to third- party 
> signatures, then multiple domain granularity includes a much  larger to 
> infinite set of potential miscreants.  With the zombie  problem being 
> rather prevalent, mailbox-domain(s) granularity is  problematic.  
> Third-party restrictions are also problematic, as this  will impact 
> normal behaviors.  Opaque identifiers offer a practical  solution.
> 
> -Doug
> 
> 
> 
> 
> 
> _______________________________________________
> ietf-dkim mailing list
> http://dkim.org
> 

-- 

   d/

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net