Trend Micro, NSSG

1737 North First Street, Suite 680 San Jose CA 95112 USA +1.408.453.6277 doug_otis@trendmicro.com

Internet Area DKIM Working Group DOSP Draft DOSP (DKIM Originator's Signing Policy) is a DNS-based mechanism for associating domain-names and asserting separate DKIM related policies for all originating header fields and parameters found in DKIM related messages. DOSP can associate an email-address with a list of signing domains, and a signing domain with a list of SMTP Clients. DOSP also provides a means to assert whether signatures are always initial provided, whether there was an effort to protect these signatures, and their role related to offering assurances, such as when an identity referencing the DOSP policy is assured to be valid. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

This document describes how signing can be related to all of the various originating header fields and parameters found in DKIM related messages. DOSP better secures the use of the email-addresses and domain-names found in message header fields and parameters. Recommended or suggested actions for a DKIM receiver are not included, and are considered "out-of-scope" for this document. The receiver is assumed to better understand their environment's impact upon the performance of DKIM signatures and how DKIM signatures are utilized within their domain. There are many uncertainties in respect to the actual usage of the DKIM protocol. These uncertainties exist for the following reasons: Intentionally vague DKIM protocol semantics Full adoption of DKIM is not implied Limited semantics for some signing domains Optional validity of email-addresses No assumed signature ordering or signing roles No direct association with the SMTP Client DOSP can assert that messages originating from a domain specified in a specific header field or parameter are all initially signed by a designated signing domain. DOSP can also assert that only complaint services are subsequently used, with an intended goal of ensuring initial signatures are not damaged or removed. The assurance of using only compliant services may enable more stringent message handling by a receiver. DOSP can also assert that an email-address domain is never used. This assertion provides a means for avoiding invalid DKIM signature spoofing of their domain. DOSP does not make distinctions between first-party and third-party signatures. Any designated signature is considered equivalent to a first-party signature for the purposes of policy evaluation. DOSP domain-name associations are only inclusive. DOSP allows the originating domain to make assertions that indicate when a referencing identity is valid or when a signing domain fulfills DOSP requirements. This is accomplished by assigning roles for various signing domains. In addition, DOSP allows signing domains to designate SMTP Clients. By allowing signing domains to designate SMTP Clients, anti-replay mechanisms can be by-passed for these SMTP Clients. The goal of DOSP is to: Fully enumerate signing practices for all originating domains Facilitate associations with all other domains Simplify steps for establishing a comprehensive DKIM policy Accommodate all practical deployment strategies Provide a means to assure email-addresses and sources A message signed with DKIM, whether or not there is also a referenced policy, does not indicate when a message is from a good or bad actor. However, DKIM signatures will allow a recipient's trust to be strengthened. Good actors establish trust. Bad actors do not. Trust is an essential prerequisite. The DKIM signature header field's 'i=' semantics or the DOSP assertions regarding the validity of related identities provide valuable advisory information. This advisory information allows the safer application of message annotations for ensuring trusted identities are properly recognized. Policy assertions convey which domains are authoritative and are able to assure valid identifiers. This information is essential for the proper recognition of valid email-addresses of trusted identities, as well as noting when a message source may require added scrutiny. The goal of DOSP is to incorporate a full range of possible signing practices. The main objective of DOSP is to establish a basis for evaluating all originating domains and their related email-addresses. As should be expected, DOSP assertions are only assurances of the message's initial state. Blocking messages from non-designated sources or for having invalid signatures will not provide sufficient protection, and is also likely to disrupt message delivery in many cases. Senders may become frustrated by delivery problems, while recipients still remain exposed to look-alike or "cousin" domain spoofing, and will be easily misled when only a display-name is initially seen. For an email-address to be considered valid, it must be signed by either a matching or a designated domain. In addition, this email-address MUST be either: fully included within the signature header field 'i=' parameter signed by a domain with a role of signing valid email-addresses containing a local-part asserted as being valid Even when an email-address is assured to be valid by one of these mechanisms, it is not reasonable to consider all email-addresses from a domain to represent equally trustworthy identities or that all follow the same practices. For the purposes of annotating messages based upon a trusted domain, local-part designations permit a domain to indicate which identities are trustworthy from their perspective. The recipient must determine independently, through various out-of-band methods, which domains or identities should be considered trustworthy. When trust is based upon a domain-name rather than a specific email-address, message annotations should differ, and should be constrained to those identities asserted as trustworthy in DOSP local-part policies.

DKIM allows a signing domain to selectively protect portions of a message from modification and to selectively vouch for the validity of an email-address when fully contained within the DKIM Signature header field's 'i=' parameter. Neither this document or prescribe specific actions for receivers to take upon completion of signature validation and policy conformance assessments. While this document allows all originating domains a means to succinctly assert domain associations and signing practices, it does not advise how messages are to be handled. While the DKIM protocol offers a verified signing domain, by design the signing domain remains unseen by the recipient. Message annotations are required before recipients benefit substantially from DKIM protections. Annotations of assured and trusted email-addresses may entail placement into various folders or the addition of distinctive markings. As with message handling in general, this document also does not define how message annotations might be accomplished. DKIM is fully independent of the SMTP Client and the .MailFrom email-address. Allowing the .MailFrom email-address to designate signing domains and assert signing practices may prevent Delivery Status Notifications (DSNs) from being sent when the email-address is forged. Allowing the signing domain to designate SMTP Clients may allow receivers to circumvent mechanisms guarding against possible message replay abuse. These two policies represent entirely optional protection strategies that may or may not prove either effective or practical. These are offered only to allow for experimentation.

Unlike IPv4 addresses, there is virtually no limit on the number of domain-names available. Registrar pricing of domain-names should remain uniform, otherwise higher fees based upon an intrinsic value established by the owner may cause them to become extortion targets. Fees could be added under a guise of being incurred due to poor email administration, for example. Initial costs for domain-names are unlikely to represent a deterrent, and it is unlikely registrars will be able to fairly withdraw domain-names due to unsolicited bulk email practices. In addition, DKIM can not directly identify the domain transmitting the message, and can not prevent abusive message replay. Abusive message replay may prove indistinguishable from bulk mailings of various types. As a result, message acceptance will likely remain based primarily upon the IP address of the SMTP Client. Abuse reporting facilitated by a DKIM signature should therefore correspond with the domain administering the SMTP Client publicly transmitting the message. When the signing domain differs from that of the domain within the originating email-address, DOSP offers a simple solution for email-address policy compliance. Just as a DKIM signature can assert an email-address is valid, a signing domain that only signs validated email-addresses can be designated as playing the role of providing valid email-addresses. This assertion remains valid even when signing domains and the email-address domains differ. A domain could also be designated as only providing a valid signature for fulfilling an assertion that all email-addresses are being signed, but that these email-addresses are not assured to be valid. While this latter role does not ensure all possible spoofing is prevented, these messages should not receive annotations indicating any assurances either. This role represents an economical alternative enabling large scale autonomous administration of domain associations. Designating domains that play the role of only providing valid signatures may be suitable for non-critical messages, where the goal may be to improve delivery acceptance. When the originating email-address domain differs from that of a provider's DKIM signing domains, DNS delegation or key exchanges are required before these domains can match. The provider would need to sign with the customer's key for messages sent using their account. DNS delegations or private key exchanges will likely involve a significant amount of detail, such as key selectors, user limitations, suitable services, key resource record's Time-To-Live, revocation and update procedures, and whether the DKIM Signature header field's 'i=' semantics should be applied as indicating valid email-addresses. This DNS delegation effort will likely involve the sharing of these details between the email provider, the domain owner, and the DNS provider. As there are many ways in which this could be accomplished, it is also unlikely for there to be consistent or standardized formats for exchanging this information. In addition, when there are any security breaches, the domain owner might be held accountable for message content that was never seen or logged by them. Protections offered by DKIM are largely related to better recognition of prior correspondents, and improved identification of initial sources when instances of abuse are reported. While DOSP may allow the receiver to detect and reject messages that appear non-compliant, the overall cases where this might happen are likely to represent a fairly small portion of the overall messages. When the receiver seeks to protect the DKIM verification process with a preliminary message filter, even acquiring DOSP policy records or DKIM keys may inadvertently leak valuable information benefiting abusive senders. The validation of DKIM and the obtaining of DOSP resource records may consequently become limited to known trustworthy domains.

Syntax descriptions use the form described in Augmented BNF for Syntax Specifications . The "base32" function is defined in and the "sha-1" hash function is defined . The function "lcase" converts upper-case ALPHA characters to lower-case. The terminating period is not included in domain-name conversions. asterisk = %x2A ; "*" plus = %x2B ; "+" hyphen = %x2D ; "-" period = %x2E ; "." colon = %x3A ; ":" semicolon = %x3B ; ";" equals = %x3D ; "=" underscore = %x5F ; "_" ldh = ALPHA / DIGIT / hyphen ; let-dig = ALPHA | DIGIT ; subdomain = let-dig [*61(ldh) let-dig] ; domain = subdomain 1*(period subdomain) ; ANY = asterisk period ; "*." FWS = ([*WSP CRLF] 1*WSP) ; VALCHAR = %x21-3A / %x3C-7E ; "!" to "~" except ";" ALNUMPUNC = ALPHA / DIGIT / underscore ; tag-value = [1*VALCHAR 0*( 1*(WSP / FWS) 1*VALCHAR)] ; tag-list = tag-spec 0*(semicolon tag-spec)[semicolon] ; tag-spec = [FWS] tag-name [FWS] equals [FWS] tag-value [FWS] ; tag-name = ALPHA 0*ALNUMPUNC ; From = "F" ; .From Originator = "O" ; .Sender/Resent-Sender/Resent-From MailFrom = "M" ; .MAIL FROM Ehlo = "E" ; .EHLO LocalPart = "L" ; left-hand side of email-address sig-policy = (From / Originator / MailFrom) ; sig-label = base32( sha-1( lcase(signing-domain))) ; 32 characters lp-policy = LocalPart (From / Originator) ; lp-label = base32( sha-1(local-part)) ; 32 characters ehlo-policy = Ehlo ; ehlo-label = base32( sha-1( lcase(ehlo-domain))) ; 32 characters Tag Function v= Version f= Flags a= Designated Signing for Address d= Designated Signing for Domain l= Designated Local-Part Flag Function A All initial messages signed N Not signing O Only compliant subsequent services employed L Local-Part policies are published T Trusted Designated Local-Part V Valid Designated Local-Part The receiver obtains the DOSP email-address domain policy using a DNS query for an IN class TXT resource record. The character strings contained within the TXT resource record are concatenated into forming a single string. The content of this concatenated string contains a tag-list based upon the ABNF format defined within this section. Unrecognized tags MUST be ignored. A policy record may be located at these domains: <sig-label>._DKIM-<sig-policy>.<email-address domain>. <lp-label>._DKIM-<lp-policy>.<email-address domain>. <ehlo-label>._DKIM-<ehlo-policy>.<signing domain>. Policies accessed with "lp-labels" should not include any designated domains.

v= Version (MUST be included). This tag defines the version of this specification that applies to the signature record. It MUST have the value 0.0. Version = %x76 [FWS] equals [FWS] "0.0" INFORMATIVE NOTE: DKIM-Signature version numbers are expected to increase arithmetically as new versions of this specification are released. [INFORMATIVE NOTE: Upon publication, this version number should be changed to "1", and this note should be delete.]

f= Flags (Optional). This tag defines a list of flags that assert various aspects of the email-address domain signing policy. flag = %x41/%x4C/%x4E/%x4F/%x54/%x56 ; "A", "L", "O", "T", & "V" Flags =%x66 [FWS] equals [FWS] flag 0*(*FWS colon *FWS flag)

This "A" flag asserts that messages carrying the email-address domain within the relevant header field or parameter are all initially signed by a designated domain.

This "L" flag asserts that local-part policy is published for the corresponding message header field. For example when a policy is published at <sig-label>._DKIM-F.<email-address domain> that has the "L" flag asserted, then local-part policy can be found at <lp-label>._DKIM-LF.<email-address domain>. This flag is not valid in Ehlo and MailFrom records.

This "N" flag asserts that messages carrying the email-address domain within the relevant header field or parameter are not initially signed. This assertion might be suitable as a means to prevent or terminate a policy record search, and to assure that no signatures are generated by this domain as a means to prevent invalid signature spoofing.

This "O" flag asserts that messages carrying the email-address domain within the relevant header field or parameter are not subsequently used in conjunction with services that may either damage or remove the initial signature. This assertion might be suitable for domains willing to forego the use of many common services where signatures might be damaged, for example.

This "T" flag asserts that messages carrying the email-address containing a designated local-part found in the 'l=' tag local-part list are considered trustworthy by the email-address domain. This flag is not valid in Ehlo and MailFrom records.

This "V" flag asserts that messages carrying the email-address containing a designated local-part found in the 'l=' tag local-part list are considered to be valid by the email-address domain. This flag is not valid in Ehlo and MailFrom records.

a= Designated Signing for Address (Optional). This list defines domains considered to be the equivalent of the respective email-address domain for the purpose of assessing policy. These domains play the role of providing valid email-addresses. When a domain is prefixed with the "*." wildcard label, then all subdomains of this domain are considered to be included in the list. The wildcard label used in the list allows a common resource record to be shared by multiple "sig-label" references. It is possible for a signing domain to be at a higher level than the respective email-address domain and not be designated. When the signing domain is not specifically listed within either designated signing domain lists (a= & d=), no policy related assurances are made. When the signing domain used to generate the "sig-label" is not found in either list, and these lists are not empty, the policy should be obtained by replacing the "sig-label" with "*" instead. In practice, this step should rarely be needed. This list is not valid in Ehlo and MailFrom records. dsa = [ANY] domain 0*(*FWS colon *FWS [ANY] domain) dsa-list = %x61 [FWS] equals [FWS] dsa

d= Designated Signing for Address (Optional). This list defines domains considered to be the equivalent of the respective email-address domain for the purpose of assessing policy. These domains do not play the role of providing valid email-addresses. These domains only provide valid signatures for the purpose of assessing signing compliance. This list also confirms SMTP Client domains in Ehlo records. When a domain is prefixed with the "*." wildcard label, then all subdomains of this domain are considered to be included in the list., The wildcard label used in the list allows a common resource record to be shared by multiple "sig-label" or "ehlo-label" references. It is possible for a signing domain to be at a higher level than the respective email-address domain and not be designated. When the signing domain is not specifically listed within either designated signing domain lists (a= & d=), no policy related assurances are made. When the ehlo-domain or signing domain used to generate the "ehlo-label" or "sig-label" respectively is not found in a list, and the lists are not empty, the policy should be obtained by replacing the "ehlo-label" or "sig-label" with "*" instead. In practice, this step should rarely be needed. dsd = [ANY] domain 0*(*FWS colon *FWS [ANY] domain) dsd-list = %x64 [FWS] equals [FWS] dsd

l= Local-Part policy published (Optional). This tag lists designated local-parts for which policy is being published. When the "l=" list is not empty in a record not referenced using an "lp-label", the "(T)rusted Designated Local-Parts" and the "(V)alid Designated Local-Parts" flags only apply when the local-part has been confirmed by this list. It is expected that it might be common for only a few email-addresses to warrant special handling where publishing separate local-part policies can be avoided. When the local-part used to generate the "lp-label" referencing the policy is not found in this list, and this list is not empty, the policy should be obtained by replacing the "lp-label" with "*" instead. In practice, this step should rarely be needed. This list is not valid in Ehlo and MailFrom records. lp = [ANY] local-part 0*(*FWS colon *FWS [ANY] local-part) lp-list = %x6C [FWS] equals [FWS] lp

The default policy assumed is the same as when no optional fields are entered in the DOSP records. This default policy makes no assurance about whether all initial messages have been signed and does not include any additional domain associations. When a policy flag is asserted, it may be necessary to list the respective email-address domains in either the "Designated Signing for Address" (a=) or "Designated Signing for Domain" (d=) list. Listing the email-address domain in the "Designated Signing for Domain" list asserts that regardless of the DKIM signature header field's 'i=' semantics, email-address should not be considered valid. When the "Designated Signing for Domain" (d=) list applies in the case of the of .MailFrom parameter, this is indicative of a valid signature satisfying a possibly asserted "(A)ll initial messages signed" flag. When both the "Designated Signing for Address" (a=) and "Designated Signing for Domain" (d=) list are empty, and the "(A)ll initial messages signed" flag is asserted, this then means that no mail originates from this domain. A domain that ensures that all messages are initially signed, and attempts to ensure that their users employ only complaint services, may indicate this extraordinary effort by asserting both the "(A)ll initial messages signed" and the "(O)nly compliant services employed" flags. This combination of flags could be helpful in overcoming phishing attempts without negatively affecting domains that assert just the "(A)ll initial messages signed" flag. Future flags may make use of the "+" symbol to indicate a logical OR of related assertions. The current ":" flag separator can be considered to represent a logical AND of related assertions.

This document may wish IANA to reserve the use of the "_DKIM-F", "_DKIM-LF", "_DKIM-O", "_DKIM-LO", "_DKIM-M", and "_DKIM-E" domain-name label. Note to RFC Editor: this section may be removed on publication as an RFC and no request is desired or registration is not considered practical.

This draft defines signing policies related to . There is no expectation this policy information is from an authenticated source. Network resources expended to acquire this information should be proportional to that needed to verify the signature. Strategies used by the receiver to limit possible amplifications that might occur with signature verification should also limit the impact of obtaining this information. The use of the SHA-1 hash algorithm does not represent a security concern. The hash simply ensures a deterministic domain-name size is achieved. Unexpected collisions can be detected and handled by using a default value.

Hector Santos, and Frank Ellermann.

#### # example.com email domain using isp.com as a signing domain # EHLO host-name mx-01.example.com. IN A 10.1.1.1 #### 2822.From policy *._DKIM-F.example.com. IN TXT "v=0.0; a=*.example.com; l=admin; f=A:T:V;" # "isp.com" sig-label hgssd3snmi6635j5743vdjhajkmpmfif._DKIM-F.example.com. IN TXT "v=0.0; a=isp.com; f=A;" #### 2821.MailFrom policy *._DKIM-M.example.com. IN TXT "v=0.0; a=*.example.com; f=A;" # "isp.com" sig-label hgssd3snmi6635j5743vdjhajkmpmfif._DKIM-M.example.com. IN TXT "v=0.0; a=isp.com; f=A;" #### 2822.Sender policy *._DKIM-O.example.com. IN TXT "v=0.0; a=*.example.com; f=A;" # "isp.com" sig-label hgssd3snmi6635j5743vdjhajkmpmfif._DKIM-O.example.com. IN TXT "v=0.0; a=isp.com; f=A;" #### 2821.EHLO policy *._DKIM-E.example.com. IN TXT "v=0.0; a=*.example.com; f=A;" # "mx-01.example.com" ehlo-label inkzgjwvtenf4zjexukzo4qknqhgwee6._DKIM-E.example.com. IN TXT "v=0.0; a=*.example.com; f=A;"