ietf-mailsig
[Top] [All Lists]

Will user-keys cause DNS cache to explode?

2005-08-01 00:47:14

When a domain attempts to establish policies that all emails be signed, email's diverse architecture may make delegating keys to mobile users or outside agencies an expedient choice. Will this delegation then create a need for these keys to be restricted to a specific local-part? While normally DNS, or DKIM for that matter, says little about local-parts beyond conventional roles, some hope user-keys within DNS will provide acceptance criteria for the entire mailbox address, including the local-part. This checking of the local-part for delegated keys is to seamlessly continue local-part restrictions which may be made by in-house servers. The goal is to assure recipients with an expectation that who they think sent the message is not being spoofed.

Obviously, no firm should give the same key to an outside agency or mobile user, as the key they use in-house. Perhaps this in-house server, in addition to restricting the local-part, may filter for links, viruses, and other objectionable content. Should DNS information include details for these possible restrictions as well? Checking the local-part could be just one of many details that an in- house system checks. Another consideration regarding the goal of assuring recipients of who they think sent the message, is that the Original Address algorithm may still allow local-part spoofing, even if there were local-part key checks. There is still room for mischief, where controlling the system signing the message is still needed for this assurance.

It is also likely that third-party signatures will become common place. Third-party signing will train a large population of recipients to look at who signed the message, rather than trusting the local-part (which few really trust). Only the message signature indicates the domain accountable for behavior, and this is where trust should be placed. Abusive behavior includes spoofing the local- part, but there is much more that could be called abusive behavior.

An ad agency could be given a key within a sub-domain of the company's domain used for email. This agency could be asked to use this sub-domain to implement 'third-party' signatures for mailbox- addresses using the normal mailbox-domain, where the local-part and other message content is simply stipulated. Also assume this key is flagged 'delegated' which allows it only to be used for third-party signatures. Also assume there can be a domain assertion mode that permits third-party signatures only when they are within the domain of the Originating Address. This would be in contrast to a mode that permits all third-party signatures.

If an ad-agency, mobile user, or any party provided such a 'delegated' key violates the trust of the company by sending _any_ content found within the message which does not meet the approval of the company, the key should be removed. There should also be a means to self "black-hole" list these in the same manner as described for 'revocation-identifiers' in the mass-reputation draft. By having the signature's domain be 'ad-agency.example.com', this provides information that a wary recipient or content filter could use to determine who they are trusting, with respect to the entire content of the message. This has another advantage, abuse history will accrue separately, and will be less of a risk to the main email domain.

With signatures that may not be bound to originating address, the real value is found when deciding whether the accountable domain enforces policy sufficiently to prevent abuse. DKIM is proposing to include keys for a list of users, along with the location of the services within DNS. While initially it is expected user-keys will not become widely used, these user-keys offer the potential for many desired features. They could be used in a scheme to provide encrypted messages between users, which is not a current feature of DKIM, but perhaps could be used for VoIP or IM.

Once Pandora's box is opened to provide user keys within DNS, how will one be able to put a lid on that box later? For those that want local-part protection, perhaps requiring an X.509 certificate be obtained through different services should be required. This would be a feature made available when these alternatives are eventually defined. While I see an advantage in using DNS to store keys related to client/server exchanges, I find it difficult to justify burdening DNS with huge amounts of data unrelated to the discovery and confirmation of the service itself. DKIM wants DNS to provide keys for the users of this service. This potentially represents several orders of magnitude of increase of the data found in DNS to support such a service.

Because there is no way to predict how this type of user-key in DNS will be used, I would suggest that it not be allowed. Those companies who feel they can not police those that they confer trust by delegating keys, with respect to sending messages on their behalf, then they should utilize a dedicated user-key service. This position may lend support to Phillip's position regarding this issue. Should a separate user-key service fail to meet the demands, at least DNS would still be functioning.

-Doug
<Prev in Thread] Current Thread [Next in Thread>