|
Re: [ietf-dkim] linkage between "originator" and "handling agent"
2005-08-17 13:40:30
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
_______________________________________________
ietf-dkim mailing list
http://dkim.org
|
|