[ietf-dkim] linkage between "originator" and "handling agent"
ietf-dkim at kitterman.com
Wed Aug 17 13:34:24 PDT 2005
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
>>> 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
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
> 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?
More information about the ietf-dkim