[ietf-dkim] linkage between "originator" and "handling agent"

[Scott Kitterman]

Douglas Otis wrote:
> 
> On Aug 17, 2005, at 7:18 AM, Scott Kitterman wrote:
> 
>> Douglas Otis wrote:
>>
>>> There are two ways to look at DKIM goals-
>>> 1- A mechanism that provides an accountable domain for the message.
>>> A number of features are available as a product of the  accountable  
>>> domain.
>>>  a) reputation accrual
>>>  b) directed abuse reporting
>>>  c) IP address independent basis for message acceptance
>>>
>> None of which relate to preventing forgery.
> 
> DKIM alone or in combination with domain-wide assertions do not  assure 
> prevention of forgery (the falsification of a sending mailbox- 
> address).  This assumption trusts the signing domain, but without  
> assurances.  The 'i=' parameter appears related to the use of user- 
> keys.  The 'i=' parameter may also declare just the domain, or not be  
> used at all.  I would also argue that user-keys are not appropriate  for 
> DNS.  Unless you are suggesting every user has their own key,  then 
> claims of preventing forgery by implementing DKIM is very  misleading.  
> The term 'forgery' is misleading and may lead to a  dangerous reliance 
> on this half measure.  I am simply asking for  better descriptive 
> language when describing the intended goal of a  domain-wide assertion.
> 
OK.  So it sounds like we actually agree that none of the number 1 items 
relate to forgery prevention.

I don't think that anyone is saying that DKIM is solve e-mail forgery. 
So I guess I don't see your point.  I don't expect DKIM to be a complete 
solution to all forgery problems.  I do expect it to be able to detect 
certain classes of forgery and enable the receiver to reject them.  If 
it doesn't why implement?

None of your response gets past the fundamental point that none of those 
things are actually useful without other 'services' that I'm figuring 
I'll have to pay for.  I'd much rather be able to actually use DKIM for 
something.  This doesn't preclude those valude added services from being 
available, I just don't want to make them mandatory to make the thing work.

>>> 2- A mechanism that is able to optionally constrain the use the  
>>> From- domain.
>>>  a) debunk spoofed messages
>>
>> I don't think debunk really captures it.  I think we are after a  
>> mechanism to allow receivers to determine if the sending domain  (yes, 
>> I know that's an amorphous term) is willing to state the the  message 
>> is authorized.

> 
> Anti-phishing and anti-forgery clearly overstate the results of a  
> domain-wide assertion in conjunction with DKIM.  While DKIM in  
> combination with domain-wide assertions, or the visibility of the  
> accountable domain, will limit sources of possible abuse, it is  
> important to be realistic about what DKIM and DKIM in combination  with 
> a domain-wide assertion provides.
> 
Where did I say it did?  In combination with a sender policy, one can 
determine if the message has been authorized by the domain owner.  If 
it's authorized, that says nothing, by itself, about it's goodness.  If 
it's unauthorized, that's information I can do something with.

> There are many problems that will need to be addressed with a domain- 
> wide assertion mechanism.  I would even argue that simply exposing  the 
> accountable domain, verified by a valid DKIM signature, would be  a 
> better means to achieve greater safety.  There are many ploys where  
> pretty names are used, or where reliance upon the MUA offering  greater 
> emphasis on unchecked headers may actually pose greater risks  to 
> recipients.  This is made worse when these recipients have been  assured 
> by some "icon" that indicates this message is DKIM verified,  believe 
> DKIM prevents 'forgery' and that the sender mailbox address  can be 
> fully trusted.  Would the recipient understand that only the  domain of 
> the From is being checked?

I don't mind exposing the accountable domain.  We seem to agree it means 
little by itself.  You want the rest of the problem to be external to 
DKIM.  I want to solve at least part of the rest of the problem (tie to 
domain owner policy) as part of DKIM.

> There are very good reasons not to rely upon the browser 'lock'  icon.  
> The domain being trusted should always be visible.  Not doing  so leaves 
> the system extremely vulnerable.  While it could be assumed  that 
> blatant criminals would not be able to retain services of a  Certificate 
> Authority, this still leaves a large window of risk.  In  the case of 
> DKIM, there is not even a CA.  In the end, the trust is  based upon the 
> signing domain.  There is tremendous value being able  to verify (and 
> see) who is being trusted.

To the extent I actually argued in favor of relying on browser lock 
icons in DKIM, I'm sure you're right.

> Once the accountable domain is visible, much of the justifications  for 
> implementing the automation of detecting spoofed messages  vanish.  A 
> list of institutions plagued by phishing which also fully  implement 
> DKIM with deterministic header conventions would enable  effective 
> filters without any domain-wide assertions as well.  Domain- wide email 
> assertions could be considered a method to indicate  implementations of 
> various present and future protocols.  The binding  of headers seems 
> rather perilous from a standardization perspective  for the reasons 
> mentioned.
> 
OK.  So, instead of defining a link between sender policy in the sending 
domain that is pretty well defined already that would enable me to 
reject certain classes of unauthorized mail in the MTA and never bother 
a user with it, it sounds like you think it would be easier to upgrade 
all the MUAs in the world.
> 
>>> To clarify basic elements involved in DKIM, versus expressing  
>>> domain- wide assertions, these two efforts should be independent.   
>>> This would  ensure a flexible language is used to express these  two 
>>> highly  independent functions.
>>
>>
>> One might, I suppose, make the arguement that the policy linkage  
>> between the sending domain and the DKIM signing domain is really a  
>> form of a very narrow reputation service.  So, on that note, you  
>> might be right, but then where's the value in DKIM signatures  alone?  
>> Is it sufficient to merit a working group?  Is it  sufficient to 
>> garner deployment?
> 
> 
> 
> There is great value in knowing who allowed abusive email.  There is  
> great value knowing who should receive complaints when abuse  appears.  
> There is great value, when those accountable for abuse are  blocked by a 
> reputation service, the innocent domains are not  inadvertently 
> impaired.  There is great value knowing where to go  when there is 
> criminal activity.  I believe just a few of these and  many more reasons 
> would be sufficient.
> 
None of which a signature alone can do without 'value added services'.

>> I do think that DKIM needs to decide if it's just some random  signed 
>> identifier or if it has a relationship to reducing forgery.   Some 
>> have indicated they see sufficient value in the signed  identifier.  I 
>> don't.
> 
> 
> I see many advantages avoiding the 'forgery' or 'phishing' issue.  I  
> suspect this will be the preverbal rat-hole deluxe.  I also see  
> tremendous value in having the administrative domain sign the  message.  
> This is not just some random signature, as you describe it.

OK.  Not random.  Arbitrary.  Unless and until it is tied to something 
the user sees, it really has little value in my book.

Clearly we will have to agree to disagree.  I understand your view that 
it has stand alone value.

What I don't understand is the arguement against SSP.  It seems pretty 
well defined.  You may believe that signature alone is worth something, 
but why not have SSP?

Scott Kitterman