ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

2005-08-23 12:54:39
On August 20, 2005 at 18:21, Douglas Otis wrote:

It appears your discussion of accountability is really something that
sits on top of DKIM, since trying to standardize "accountability"
seems impractical.

I do not understand what you mean by standardized accountability.
Either the domain permits and can stop abusive behavior, or they can
not.  Being held accountable reflects this simple expectation.  DKIM
goals should ensure this remains a reasonable expectation.  

Accountability requires enforcement policies, and I think we can
all agree that DKIM should not define these.

DKIM should provide the mechanism to facilitate accountability in
an acceptably reliable fashion.

There is a danger if accountability is fixed for all.  Different
entities play different roles in the transmission of a message.
These roles imply different levels of responsibiliy, which can imply
different levels of accountability.  If the accountability framework
that is built-in on top of DKIM is fixed, then entities will be very
cautious when they sign to avoid being accountable for something they
do not want to be.

Therefore, you are implying that domains may practice policies that
selectively sign messages based on what they want to account for.
For example, an ISP may sign all messages from their customers that
submit messages for transmission, but not sign messages that pass
through a forwarding service they offer to customers (regardless if
the messaging being forwarded is signed or not).

Things like anti-spoofing and anti-forgery should not be part of DKIM?

Attempts to directly address anti-spoofing with DKIM risks creating
problems that may limit wider deployment.  Already there is the problem
with From -> Sender, and per user-keys due to expectations the signature
is bound to some mailbox address.  Both of these issues entail a fair
amount of risk.  Unfortunately these efforts may only increase
recipients susceptibility, rather than the intended protections.

You seem fixated on mailbox-level forgery when no one is really
discussing it wrt DKIM.  Please focus your arguments on domain-level
forgery, which appears to be what DKIM currently tries to address.

You seem to be stating that any domain-level forgery protection is
impossible without mailbox-level forgery protection, but I am not
convinced of this.

Yes, within a given domain, one person can attempt to forge the
identity of another person within the same domain.  However, it
appears DKIM does not want to address this problem.  It only wants to
address cases where one domain tries to forge another (here is where
SSP plays a critical role).  Forgery within the scope of a single
domain is outside of DKIM's scope.

If DKIM can provide domain-level forgery protection, domains then
only need to manage forgery among the mailboxes under its control:
a divide-n-conquer strategy.

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

<Prev in Thread] Current Thread [Next in Thread>