[ietf-dkim] A proposal for restructuring SSP
dotis at mail-abuse.org
Mon Jan 28 18:13:19 PST 2008
On Jan 27, 2008, at 8:09 AM, Wietse Venema wrote:
> Bill.Oxley at cox.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.
> 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
Although raised as an issue for requirements in:
Since then, a draft illustrating how SSP could be extended has been
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
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.
More information about the ietf-dkim