Re: [ietf-dkim] A proposal for restructuring SSP

On Jan 27, 2008, at 8:09 AM, Wietse Venema wrote:

> Bill(_dot_)Oxley(_at_)cox(_dot_)com:
> > business customers who have no clue on how to manage DNS or do DKIM  
> > which rather slows adoption rates. Without this the only people  
> > doing DKIM will be the spammers (most of my currently signed mail  
> > is from spammers) and large phished entities like paypal. Now since  
> > I have a speaking relationship with paypal I dont need to use SSP  
> > for them.
> Bill,
>
> While time leaks away in disgreements on even simple things, may I  
> show an example how one DKIM private key could be used to provide  
> valid first-party signatures for multiple domains.
> - Implement DNS DKIM records as CNAMEs to records that are shared   
> by multiple domains, instead of giving each domain its own.  You   
> could share the same record with all domains, but don't have to.
> - Store the private key's NAME in the n= field of the real DKIM   
> records, so the signing software can figure out which private key   
> to use.  Or find some other way to clue in the signing software.
> - Sign with d=customerdomain, instead of d=providerdomain.
>
> By signing with a first-party signature, the verifier's job  
> simplifies greatly. But doing so also isolates that domain's DKIM  
> reputation from the DKIM reputations of other domains, for better or  
> worse.
Although raised as an issue for requirements in:
https://rt.psg.com/index.html?q=1360

Since then, a draft illustrating how SSP could be extended has been  
provided:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-02.txt

CNAMEs pointing to public keys requires an ongoing record co- 
ordination between providers and their customers.  A co-ordination  
that requires specialized signing and their customer's routine re- 
mapping of CNAMEs to the provider's current key locations.  Public key  
locations are expected to change whenever the key itself changes.  DNS  
domain delegation is a similar alternative that places the re-mapping  
process into the hands of a single entity.
CNAMEs or DNS delegation require specific provisions before customers  
can authorize the providers to sign on their behalf.  Specific  
provisions means DKIM public key redirection requires a premium  
service.  The service that includes public key redirection can not be  
managed autonomously.  In addition, email servers and name servers  
might represent an interaction between three different organizations  
managing key records to permit a customer's signature.  Such co- 
ordination will be expensive to manage, and effectively means  
providers will control their customer's private keys.  Private keys  
that "belong" to the customer, but where a customer might never see  
them.  When there is a problem, by redirecting to a provider's public  
key, the domain owner thereby becomes culpable with this dangerous  
transparent authorization.
When an outsourcing provider experiences a breach in security,  
thousands of different domains could become imperilled.  Notification  
of a single breach may require thousands of domains to be listed.   
Those listed would be those domains whose security may have been  
compromised by the exposure of perhaps a single provider's private  
key.  Costs related to managing these transparent key redirect  
authorizations also  precludes scaling the authorization mechanism to  
encompass mailing-lists, for example.
The TPA-SSP alternative does not require the provider's customers hand  
over their private keys or name space.  When there is a security  
breach, only domains whose systems had been compromised need to be  
listed in a security report.  TPA-SSP represents a safe, low cost  
solution for third-party authorizations.
When thousands of a provider's customers are using a common key, the  
provider's servers become high profile targets.  These high profile  
targets can be attacked by exposing the private key, or by  
successfully spoofing the identify of the customer during message  
acceptance.  TPA-SSP does not represent transparent authorization, so  
when there is a problem, the provider would be contacted first.  By  
not having a transparent scheme, any security compromise would be easy  
to report and to resolve.  The authorization itself could be done by  
the customer autonomously, without specific signing provisions being  
established.  TPA-SSP allows DKIM authorization to become a safer low  
cost option for the customer.
When an email authorization scheme is define by providers, their  
desire is to shift culpability and support onto the often hapless  
customer.  Providers must be held responsible for the security of  
their servers, and required to act when abuse is discovered.  The non- 
transparent authorization scheme provided by TPA-SSP ensures a  
culpable domain remains apparent.  Transparent schemes based upon  
CNAME redirection will be expensive to manage, and represents a  
security risk as knowing who to contact is unclear.
DKIM does not identify individuals, nor provides results suitable to  
be directly displayed to the recipient.  There is no reason for third- 
party authorization to be transparent.  In addition, TPA-SSP will not  
increase the amount of overhead when compared against the use of a  
CNAME.  SSP should at least define a flag that indicates when TPA-SSP  
is being used.
-Doug




_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html