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

[Douglas Otis]

On Aug 23, 2005, at 12:49 PM, Earl Hood wrote:

> On August 20, 2005 at 18:21, Douglas Otis wrote:
>
> DKIM should provide the mechanism to facilitate accountability in
> an acceptably reliable fashion.
>
> Therefore, you are implying that domains may practice policies that
> selectively sign messages based on what they want to account for.


Signing will have greater value for a legitimate sending domain.  An  
attractive feature of DKIM should include an ability to quickly  
correlate abuse and facilitate feedback aimed at rapid control.   
Signatures provide a means for the sending domain to add account  
tracking tags.  I strongly feel this should be done as a standardized  
convention.  This tagging should allow opportunistic identifications  
of authors, without any formal association through various records.   
Attempts to publish all associations needed at the author level would  
be prohibitive, but opportunistic methods where the MUA captures  
bindings of identifiers would be practical, and this also allows the  
detection of cross-domain forgery, even when no outbound server  
offers any mailbox-address constraint.  Clearly, less is much more.


> 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).


Not re-signing a message already signed makes good sense.  Passing  
unsigned messages retains the tracking difficulty which benefits no  
one but the abusers.  Getting to the bottom of a problem as quickly  
as possible remains in the interest of the domain offering transit,  
as well as their recipients.  This would provide motivation to ensure  
all messages are signed, as well as not re-signing previously signed  
messages.  Speed is of the essence in stopping and preventing abuse.   
Don't get in the way.


>
>>> 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.


Once anyone suggests DKIM will protect the mailbox-domain from  
unauthorized use, this becomes an endless debate with respect to  
which header's mailbox-domain is involved.  Whether first-party or  
third-party signing is authorized.  Which mailbox-address should be  
considered within a header.  On and on.  Don't forget the need to  
consider systemic effects.  Until there can be a reasonable  
expectation _anything_ considered "protected" is sure to be seen by  
the recipient in the same manner as it is being assured, it remains a  
fool's quest.  Worse, these efforts likely create false assurances  
and endless administrative snags.  The simpler the better.  Let's  
lighten the load at the onset.  There is always next semester.


> 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.


Within the signature header, there should be an assertion what level  
of binding is needed to best protect the identity of the message's  
author.  As MUAs are next to worthless at making assurances beyond  
pretty names, a new generation of MUAs is needed.  These newer MUAs  
should be capable of capturing the related details seen with a  
particular message to be able to opportunistically offer "author"  
level protections.  In the case where the signing assurance indicates  
only a mailbox-domain and the signing-domain should be included  
within the MUA's binding, then with just this single capture, the  
entire domain remains protected.  Communicating this information  
directly within the message itself removes the need for a domain-wide  
assertion.  If the recipient never received mail from some entity, it  
would not likely as successful as a phish anyway.   I would also  
expect that part of the MUA's capture process, the user would be  
shown the signing domain.


> 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.


Here is where SSP derails when there are efforts to directly protect  
mailbox-addresses.  I see value where a domain-wide assertion  
indicates the use of DKIM, but I do not see value attempting to  
indicate there is some type of mailbox-address protection without  
that enabling an exploit.  Suggesting that a mailbox-domain must  
always be signed, and perhaps signed by domain x, y, or z creates  
problems, as I have mentioned.


> 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.


I am of the view that DKIM without direct association with mailbox- 
addresses offers tremendous value.  Mixing DKIM with mailbox-address  
will likely offer negative benefits.

-Doug