[ietf-dkim] Re: Domain Ownership

[Douglas Otis]

On Nov 23, 2005, at 1:03 AM, Hector Santos wrote:

This is long, but I will try to be brief.


> The only reason the so call "freedom" exist is simply because there  
> was no controls in place before, hence the major exploitation and  
> abuse of the domains.

You are describing current practices, permitting the operation of  
list-servers for example, as abusive.


> You are trying to remove all rights to control the domain owner's  
> property and you really haven't consider the idea the email service  
> may not want to get involved in allowing blatant fraudulent usage  
> of restricted domains.

As the true source of an email-address can not be verified, the email- 
service (signing-domain, client IP-address, or host-name) must be  
held accountable for abuse.  The email-service provider should find  
methods to restrict abuse before being accepted under their auspices.

Just because these email-service identifiers are not apparent to the  
recipient, this does not justify shifting the burden of  
accountability onto the email-address domain owner.  If the desire is  
to hold the email-address domain owner accountable, then a different  
model like S/MIME or OpenPGP would be appropriate.


> You are making an incorrect assumption that services will want this  
> FREEDOM without any sort of verification.

When acceptance is based upon the DKIM signature, the signature  
itself acts as a means for verification of the entity that _must_ be  
held accountable.


> Even then, DKIM/SSP allows for 3rd party signing, if this what the  
> email service wants to offer.

This is a dubious claim that third-party signing will be allowed,  
when authorization misuse shifts accountability to the email-address  
domain owner and is already prevalent.


> I took a quick survey of my customers a few weeks ago and BY FAR,  
> all of them wanted control of the usage of their domains by their  
> users.  They want the flexibility on a security group profile  
> (domain) basis. Some want to allow the freedom for some domains,  
> for other domains they do not.

A method to indicate a desired constraint may be appropriate, at this  
time, for transactional email.  There are alternative ways to signal  
this desire while also avoiding unfair treatment and the overhead  
incumbent with an authorization record.  The alternative is needed to  
ensure a mode of use remains available that supports current  
practices.  As it happens, the alternative also offers improved  
spoofing protections.


> Not every ISP service is a PUBLIC service bureau Doug.  A good  
> example, off hand, is ISP for car dealerships, each with a domain  
> reflecting the car dealership.  They don't want spam just like the  
> next guy and they don't want these "high-value" domains exploited  
> externally.

The integrity of delivery is important across the entirety of email- 
address domain owners.  Cached assertions contained within signatures  
may not offer prohibitions without a prior correspondence, but then  
the DKIM signature will still act as a touchstone, and improve the  
accuracy of filters.  Without a prior exchange with an entity, being  
asked to update your account will stand-out like a sort thumb.   
Binding advice offers better protections from look-alike domains,  
which is already the next move in this game.


> Your solution KEEPS the doors open to status quo exploits across  
> the board. Your solution would prevent the controls of restrictive  
> domains across the board. The core signature is NOT enough, with or  
> without OPID.  A SSP is essential to obtain optimal benefits.

The alternative to SSP would be more effective at abating more types  
of exploits.  The obvious domain poaching spoof would be abated, and  
the look-alike spoof would also be made much more obvious to the  
recipient.  In addition, current practices would not be affected.


> Just consider even if you had a OPID concept. You would still need  
> a deterministic control to validate its usage.

I assume you mean the opaque-identifier _option_.  Indeed, the  
signing-domain should signal when this option may improve upon the  
isolation of the message's author from within the signing-domain.   
This information could be derived from a Radius server, for example.   
Keep in mind, the signing-domain establishes the trust.  Should the  
signing-domain becomes known for messing up O-IDs, then not mandating  
an association between the signing-domain and the email-address  
domains offers greater independence for the email-address domain  
owner.  They could send a message that they are about to change  
providers, and then simply change providers.

-Doug