Re: [ietf-dkim] Re: Forgery complexities

On Aug 29, 2005, at 4:25 PM, Dave Crocker wrote:
> > > 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.

The significance of the hash including various headers should not be  
assumed to offer any specific assurance of these headers prior  
validity.  The significance of the signature and what it may  
encompass only indicates what the signing domain acknowledges as  
having transmitted.

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

What is the goal attempted by the DKIM?  As you have indicated, DKIM  
does not protect against forgery of From headers prior to signing.   
The old expression, garbage in garbage out would seem to apply.  If  
there is any protection, this would be prior to DKIM.  The level of  
protection in this regard would be related to trusting prior  
validations made by the signing domain and would be unrelated to  
DKIM.  I would expect a normal application of DKIM would be simply  
signing outbound messages without performing any checks with respect  
to the related privileges associated with a specific mailbox domain.   
This would reflect current common practices.

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

Suggesting that DKIM prevents forgery would be misleading.  DKIM  
provides an accountable domain.  SSP provides mailbox-domain  
authorizations which may limit possible sources of abuse.  Describe  
the goal or the intent of the mechanism without over-stating or  
misconstruing its purpose.  I think the rather nebulous descriptions  
in the current charter does not adequately describe the intended  
goals.  Considering DKIM and SSP as separate efforts seems well  
justified.  There should be commensurate goals expressed separately  
for each effort.

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

I think this question makes the point.  What is meant by suggesting a  
mechanism is related to solving the forgery problem?  This brings  
forth expectations that this mechanism will resolve to the originator  
or author.  When someone fakes a message, what are they faking?  As  
signatures are unrelated to the originator or author, it would  
fallacious to say a signature solves the forgery problem.  I will  
assume forgery before a DKIM signature is applied is an equally  
significant problem.  The real goal is verifying the domain held  
accountable for their governance relating to preventing abusive  
behaviors.  One such behavior may include forgery, but this is not  
directly related to DKIM nor specifically addressed by SSP.

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

SSP attempts to apply mailbox-domain authorizations which may limit  
possible sources of abuse.  Once such abusive behavior may include  
forgery, but this is not specifically addressed by SSP.  I still  
think the lead-in phrase and the suggestion that headers are  
"authenticated" is misleading.   It can be stated in ways where the  
goal is much better understood.

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

A domain may do any number of checks, validations, pre-filtering,  
rate-limiting, puzzle solving, or account debiting all of which are  
unrelated to DKIM.  DKIM verifies the domain in conjunction with the  
message.  Whatever claims are made regarding the content of the  
message are beyond the mechanisms related to DKIM which only verify  
the accountable domain.  As a result, it would be confusing to  
suggest these other possible checks are somehow part of DKIM.

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

Talking about forgery and then claiming that DKIM authenticates  
headers skirts dangerously close to making that claim.

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

I was more concerned about the specific claim made in the charter.


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

I have been attempting to have a discussion related to the goals and  
the possible threats related to the DKIM and SSP mechanisms.   It  
would seem appropriate to first agree what the related intent or  
goals are for these mechanisms before proceeding into more detailed  
discussions.  It seems you remain unwilling to describe what you  
think the goal would be related to DKIM as the base.
-Doug

_______________________________________________
ietf-dkim mailing list
http://dkim.org