Re: [ietf-dkim] Not exactly not a threat analysis
2005-08-16 11:19:09
On Aug 16, 2005, at 8:03 AM, Arvel Hathcock wrote:
Verifying an accountable domain will not prevent a
mailbox-address from being forged (falsified).
We can change the draft charter language to make this clearer.
Instead of
"Forgery of headers that indicate message origin..." it could be (IMO)
"Forgery of the domain found in an RFC2822.From header..."
The public will understand anti-forgery as protecting the identity of
the author. I have never received a message from just a domain.
Providing an assertion that the From domain must be related to an
accountable domain does not prevent forgery (the falsifying of the
mailbox-address) and calling this anti-forgery for the domain is
misleading. Perhaps one could call this a domain exclusivity assertion.
With this exclusivity or dominion asserted, the From header requires
a related accountable domain to exchange these messages. As this
mechanism by itself does not prevent forgery, it is misleading to
describe this as an anti-forgery mechanism. The mechanism allows
the From domain to assert a requirement for a related accountable
domain, but assurances beyond this assertion of dominion is purely a
function of the accountable domain.
Asserting that the From mailbox-domain must
be signed by the same domain, or even a sub-domain,
may reduce possible sources of forgery, but it does
_not_ prevent forgery, such as the falsification of the
local-part.
Agreed. So we'll shy away from grand claims concerning the total
elimination of domain forgery (no such claim is made anywhere
anyway that I've seen). Now, since total elimination of forgery is
not a realistic goal, I'll happily take a *reduction* in forgery
any day and so will any responsible domain owner. Can you agree
with that statement?
A reduction in the possible sources of forgery does not assure a
reduction in forgery. Keep it clear what this mechanism provides.
This mechanism allows a From domain to assert a requirement for a
related accountable domain. What that assertion means with respect
to any number of issues should not been seen as a function of DKIM or
even this mechanism. This mechanism has nothing to do with DKIM, and
nothing to do with forgery. What this mechanism provides depends
fully upon the accountable domain.
What this From-domain dominion attempts to achieve is a means to make
the accountable domain inherently visible. (This of course ignores
several problems related to MUA presentation.)
Levels of assertions:
1 - No assertions.
2 - From-domains accompany an accountable domain.
3 - From-domains accompany an accountable domain within the domain of
the From.
4 - From-domains accompany an accountable domain that is the same as
the From.
Did I miss an obvious assertion?
You will also notice that I did not limit this assertion to just that
of DKIM. There is no reason to do so.
If the domain is large and depends upon the network
address to authenticate users, then claims that DKIM
prevents forgery would be irresponsible, even when the
From mailbox-domain is restricted to being signed by
the same domain.
I totally do not understand that. What do you mean "network
address to authenticate users"? Is this the IP you're talking
about? How does that bear on whether a domain's signing policy can
prevent unauthorized use in the RFC2822.From or not?
I was attempting to clarify that some domains will be unable to make
an anti-forgery claim regardless of these assertions being
described. An assertion that a From-domain must accompany a related
accountable domain does not assure there is any anti-forgery
protection provided or that any message is sent by those using an
authorized mailbox-address. This assertion does not require DKIM
either.
Considering anti-forgery or anti-phishing out of scope
for DKIM would increase a focus upon what DKIM
is actually providing.
Anti-phishing, ok, because we'll all just rathole on that topic.
Anti-forgery, no, absolutely not. If both these are out of scope,
what then is the real-world problem DKIM is trying to address?
The real-world makes a decision to accept messages based upon the
reputation of the client attempting the offer. Currently this
decision is largely based upon the IP address, but this may create a
great deal of collateral damage resulting from extensive sharing of
IP address space. Often this potential damage is mitigated by
tolerating a higher level of abuse. At one time not that long ago,
just IP address reputation provided greater than 90% protection from
abuse.
Abusers have since found ways into these larger domains to hide in
the crowd, or use the Delivery Status Notifications as a type of back-
door by taking advantage of those that don't use a reputation
service, and process messages after acceptance. They have also found
ways to commander IP addresses. There are new nastier techniques
emerging.
Depending upon the nature of the IP address reputation list and the
profile of the recipient, the success rates for IP address
reputations vary greatly, but many see a reduction by more than half
of the sources of abuse. No one suggests this is good enough. A
reduction of this size still permits an inordinate number of abusive
messages.
Moving to the name space has advantages in that many of today's
chinks are related to the IP address weaknesses. A signature has
advantages related to enduring forwarding as well. A name permits
closer cooperation and demonstrates a level of accountability. These
two features combined should permit a much lower tolerance for
abuse. A name can safely carry the history of the owner, whereas an
IP address can not.
Is it that we don't have enough inputs into our filtering engines
today and we just MUST have a signature based one? Or is it that
email users are routinely seeing unauthorized domain use in the
RFC2822.From?
As a general rule, don't look at behavioral tactics designed to avoid
today's protection schemes. I routinely see these From addresses only
depend upon the pretty name to fool recipients. These tailored
protection schemes will be like chasing tails attempting to prevent
every ploy. What is needed is a better identifier for a stronger
protection scheme based upon the reputations of these entities. This
type of approach can adapt, as reputation can address every trick.
Domain assertions are fine. Just don't ascribe these assertions as
being a solution to end forgery, or as married to just DKIM. These
assertions are independent of the DKIM mechanism.
Everything I've seen leads me to believe the problem is the
second thing. For example, "Forgery of headers that indicate
message origin is a problem for users of Internet email." - this is
the *first sentence* of the proposed charter. Also: "DomainKeys
Identified Mail (DKIM) defines a simple, low cost, and effective
mechanism by which cryptographic signatures can be applied to email
messages, to demonstrate that the sender of the message was
authorized to use a given email address." This language definitely
needs tweaking but the thrust of the statement is clear -
unauthorized use (read: forgery) is what DKIM is trying to
address. Are we not in agreement as a group on this point?
I find this language over-reaching and unrealistic. The signature
only verifies an accountable domain, anything beyond that is
conjecture. By sticking to this language, the group may find
themselves chasing after some holy grail and end up with nothing.
What is wrong with establishing an accountable domain? This
accountable domain may be bound to other headers within the message
by independent mechanism that are beyond the scope of DKIM.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: [ietf-dkim] Not exactly not a threat analysis, (continued)
- RE: [ietf-dkim] Not exactly not a threat analysis, James Scott
- Re: [ietf-dkim] Not exactly not a threat analysis, Arvel Hathcock
- Re: [ietf-dkim] Not exactly not a threat analysis, Douglas Otis
- Re: [ietf-dkim] Not exactly not a threat analysis, Earl Hood
- Re: [ietf-dkim] Not exactly not a threat analysis, Douglas Otis
- Re: [ietf-dkim] Not exactly not a threat analysis, Arvel Hathcock
- Re: [ietf-dkim] Not exactly not a threat analysis,
Douglas Otis <=
- Re: [ietf-dkim] Not exactly not a threat analysis, Arvel Hathcock
- Re: [ietf-dkim] Not exactly not a threat analysis, Michael Thomas
- [ietf-dkim] semantics of message signing, Keith Moore
- Re: [ietf-dkim] semantics of message signing, Jim Fenton
- Re: [ietf-dkim] Not exactly not a threat analysis, Hector Santos
- Re: [ietf-dkim] Not exactly not a threat analysis, Earl Hood
- Re: [ietf-dkim] Not exactly not a threat analysis, SM
- Re: [ietf-dkim] Not exactly not a threat analysis, Douglas Otis
- Re: [ietf-dkim] Not exactly not a threat analysis, SM
- Re: [ietf-dkim] Not exactly not a threat analysis, Earl Hood
|
|
|