[ietf-dkim] Re: opaque-identifier scaling

[Douglas Otis]

On Nov 1, 2005, at 8:23 PM, Hector Santos wrote:

> DKIM requires change but not as much as your ideas will require and  
> I don't
> believe it offers the strength you claim.

Binding an email-addresses to the provider and prohibiting third- 
party services such as list-servers is a change being required by  
SSP, once the effects of reputation are considered.  The message  
replay abuse problem still has not been resolved, which should be,  
once the effects of reputation are considered.  I can see why no one  
wants to consider reputation.  Once you include the effects of  
reputation, the SSP mechanism falls apart.

There is not much value in DKIM without being able to use the  
verification of the signature as a basis for accepting messages.  I  
don't care what is _in_ the message, provided the administrator of  
the system gets rid of abusers.  Simple and the signature makes it  
very clear where to complain.  Sweet.  What you want is far more  
disruptive by insisting that an email-address can only be carried by  
a particular email message transport system.  Of course this only  
changes the nature of the problem, while offering no real solution.   
It is nutty to think that abusers can not sign emails to continue  
spoofing domains unabated.

You worry about being excluded, but the only way this approach works  
is within a closed system.  Shut down the registrars, there are  
enough domains in use.  ; )


> So now we have a network of "Member" Distribution?  Sounds like the  
> old
> fidonet nodelist to me where each Friday the "node diff" was  
> distributed
> across the network to members.
>
> Problems:
>
> - Is there any restriction on membership?
> - What if you (senders) don't comply? Do things different?
> - Who does the sending of this list?
> - What is the schedule?
> - Do you have a ZONE, NET, HOST, NODE distribution topology?

It is clear that you have not understood the mechanism.  The opaque- 
identifier and related revocation would be an option for domains that  
experience a message replay abuse problem and want to mitigate the  
damage it may have on their reputation.  Of course, the domain could  
elect to ignore the problem and hope their signature still offers  
some acceptance value.  Most, I suspect, would see value in defending  
their signature.

The revocation record would be self-published within their domain in  
the same fashion as the keys.  If the task of publishing the  
revocation records proves too burdensome, they could delegate the  
revocation zone to a provider that specializes in providing the  
service, perhaps in conjunction with Abuse-Feedback Reporting (AR).   
I doubt most domains would see a replay problem rise that that level.


> I thought so.  So now we must use CVS AND DNA which is a most  
> definitely a
> "Batteries Required" disclaimer I must add to my documentation.

When defending the DKIM system against a DoS attack, the CSA  
mechanism offers a solution.  This same record can also make a server  
level assertion that all transports from this domain must have DKIM  
signatures.  If not, it is not us.  This could defeat some routing  
exploits.  If you read the documents I published, this is explained  
as a mitigation strategy for DoS and Replay issues.  I don't see how  
batteries are required as the CSA record is far less complex than the  
SSP record.  Neither of these records would be seen as a dependency  
for DKIM?


> 2) CSV requires a fundamental change across the board for ALL mail  
> senders
> since it is incompatible with 821 current relaxed provisions for  
> HELO/EHLO.

Again it is clear by your statements that you do not understood the  
CSV-CSA mechanism which is surprising. I see DNA as perhaps out of  
scope, but not beyond merit.  CSA records however could offer name- 
based DoS protection.  Whether this solution gets mentioned would be  
a tough call in my view.  I still think these options should be  
considered and what problems they prevent.

-Doug