DKIM Working Group M. Thomas Internet-Draft Cisco Systems Intended status: Informational September
15,2006 Expires: March 19,5, 2007 Requirements for a DKIM Signing Practices Protocol draft-ietf-dkim-ssp-requirements-01draft-ietf-dkim-ssp-requirements-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 19,5, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract DomainKeys Identified Mail [DKIM] [I-D.ietf-dkim-base] provides a cryptographic mechanism for domains to assert responsibility for the messages they sign.handle. A related mechanism would allow an administrator to publish various statements about their email accountabilityDKIM signing practices. This draft defines the requirement for this additionalmechanism. Requirements Language 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 RFC 2119 [RFC2119]. Table of Contents 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 56 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 67 4. UseSSP Problem Scenarios . . . . . . . . . . . . . . . . . . . . 8 4.1. Problem Scenario 1: All Mail Signed with DKIM . . . . . . 7 4.1.8 4.2. Problem Scenario 1: Bigbank.example.com2: Illegitimate Domain Name Use . . . . . 9 4.3. Problem Scenario 3: Domain Sends No Mail . . . . . . . . . 10 5. SSP Deployment Scenarios . . . . 7 4.2. Scenario 2: DKIM Signing Complete State. . . . . . . . . 8 4.3.. . . . . . 11 5.1. Deployment Scenario 3:1: Outsourced First PartySigning . . . . . . . . 8 4.4.11 5.2. Deployment Scenario 4:2: Determinism in Lookup Mechanism . . 11 5.3. Deployment Scenario 3: Resent Original Mail . . . . . . . 11 5.4. Deployment Scenario 4: Incremental Deployment of Signing . . . . . . . . . 9 4.5.. . . . . . . . . . . . . . . . 12 5.5. Deployment Scenario 5: IncrementalTransport Scenarios . . . . . . . . 12 5.6. Deployment Scenario 6: Human Legibility of SigningPractices . . . 13 5.7. Deployment Scenario 7: Cryptographic Downgrade Attacks . . 13 5.8. Deployment Scenario 8: Extensibility . . . . 9 5. Requirements. . . . . . . 13 5.9. Deployment Scenario 9: Security . . . . . . . . . . . . . 13 6. Requirements . . . . . 11 5.1. Discovery Requirements. . . . . . . . . . . . . . . . . . 11 5.2. Transport requirements. . 15 6.1. Discovery Requirements . . . . . . . . . . . . . . . . 11 5.3. Practice and Expectation Requirements. . 15 6.2. Transport requirements . . . . . . . . 12 5.3.1. Negative Commentary. . . . . . . . . . 16 6.3. Practice and Expectation Requirements . . . . . . . 12 5.4.. . . 16 6.4. Extensibility and Forward CompatibiltyCompatibility Requirements . . . 15 6.19 7. Security Requirements . . . . . . . . . . . . . . . . . . . . 16 7.20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8.21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10.23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1.24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10.2.24 11.2. Informative References . . . . . . . . . . . . . . . . . . 2024 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 2125 Intellectual Property and Copyright Statements . . . . . . . . . . 2226 1. Preface The purpose of this draft is get out into the open a range of issues related to the perceived need for a signing practices information service primarily focused on DKIM. This document is intended to document well-agreed upon problems and requirements, in addition to less well-agreed upon requirements in an attempt to capture the issue as well as generalize the requirement as much as possible. These latter requirements will be noted as "[PROVISIONAL]" to indicate that there is not yet solid consensus, or that the problem is not well understood. A winnowing process is envisioned where the more difficult and/or speculative problems/requirement will be eliminated unless concrete problems with proven constituencies can be demonstrated, along with reasonable plausibility that they do not contradict more well agreed upon requirements. 2. Definitions o Domain Holder: the entity that ultimately controls the contents of the DNS subtree starting at the domain, either directly or by delegation via NS records it controls. o First Party Address: For DKIM, a first party address is defined to be the [RFC2822].From address in the message header; a first party address is also known as an Author address o First Party Signature: a first party signature is a valid signature where the domain tag (d= or the more specific identity i= tag) matches the first party address. "Matches" in this context is defined in [I-D.ietf-dkim-base] o Third Party Signature: a third party signature is a valid signature that does not qualify as a First Party Signature. Note that a DKIM third party signature does is not required to correspond to a third party address such as Sender or Listid, etc. o DKIM Signer Complete: the state where the domain holder believes that all legitimate mail purportedly from the domain was sent with a valid DKIM signature. o The Protocol: in this document, The Protocol is used as placeholder for a protocol that will meet the requirements set in this draft. 3. Introduction The DomainKeys Identified Mail working group is chartered to create a base signing mechanism for email. This work is contained in [I-D.ietf-dkim-base]. In addition there are two other documents [I-D.ietf-dkim-overview] and [I-D.ietf-dkim-threats] which give an overview and a threat analysis of the chartered work. This draft reflects the requirements for the last part of the chartered work to define a protocol to publish DKIM signing practices. While the base signing document defines a mechanism for signing and verifying DKIM signatures, there has been a great deal of interest in a signing practices protocol. The most pressing case seems to be the bid down attack inherent with almost all systems that allow optional authentication: how does a receiver know whether or not it should expect a message to contain authentication information? For email this is an especially difficult problem since there is generally no a priori knowledge of a sending domain's practices. If a protocol could be developed for a domain to publish its DKIM signing practices, a message verifier could take that into account when it receives a unsigned piece of email. This draft is organized into two main sections: a UsageProblem and Deployment Scenario section which attempts to describe some common usage scenariosdescribes the problems that DKIMThe Protocol is likelyintended to be deployed in andaddress as well as the problems that are not solved by DKIM alone.deployment issues surrounding the base problems. The second section is the Requirements that arise because of those usage scenarios, in addition to more basic protocol requirements.scenarios. 4. UseSSP Problem Scenarios The email world is a diverse worldplace with many deployment scenarios. This section tries to outline some usage scenarios that it is expected that DKIM signing/verifying will take place in, and how a new protocol might be helpful to clarify the relevance of DKIM signed mail. 4.1. Problem Scenario 1: Bigbank.example.com There seems to be a class of mail -- mostly transactionalAll Mail Signed with DKIM After auditing their outgoing mail from high value domains -- that are the targetand deploying DKIM signing for all of phishing attacks. In particular, the phishing scams forge the [RFC2822].From address in additiontheir legitimate outgoing mail, a domain could be said to spoofing much ofbe DKIM signing complete. That is, the contentdomain has to trick unsuspecting users into revealing sensitive information. Domain holders sending this kind of mail would likethe best of its ability to give better guaranteesinsured that mail sent in their name is with the consent of the domain holder. The first step is, of course, to use DKIM-base to signall of the outgoingmail so that a receiver can make a determination that the mail islegitimately purporting to have come from the domain holder in question. The problem with this scenario isthat domain contains a valid DKIM signature. A receiver in the general case doesn't know what the practices are for a given domain, or what their expectations are for unsigned mail. Thus the receiver is at a disadvantage in that it does not know if it should expect mail to be signed from a given domain or not. This knowledge gap leads to a trivially exploitable bid-down attack where the attacker merely sends unsigned mail; since the receiver doesn't know the practices of the signing domain, it cannot treat the message any more harshly for lack of a valid signature. An information service which allowed a receiver to query for thosethe practices and expectations of the sending domain when no valid signature is found could be useful to close the gap where an attacker merely sends unsigned mail to exploit a bid down attack. It is assumed that receivers wouldin closing this gap. A receiver could use this information to treat such questionable mail with varying degrees of prejudice. Note that for the foreseeable future, DKIM signature breakage for unrestricted use patterns (ie with users and especially(eg where users are members of mailing lists)lists, etc) will likely suffer occasional damagenon-malicious signature failure in transit. While probably not a large percentage of total traffic, the kind (quality) of breakage may be a significant concern for certainthose usage patterns. As such, thisThis scenario defines a more limited situationwhere the risk of a legitimate piece of mail being mislabeledsender cannot set any expectation as unsigned outweights the risk of illegitimate mail being delivered in the eyesto whether an individual message will arrive intact. Even without that expectation, a receiver may be able to take advantage of the sender.knowledge that the domain's practice is to sign all mail and bias filters against unsigned or damaged in transit mail. This information should not be expected to be used in a binary yes/no fashion, but instead as a data point among others in a filtering system. 1. Mail with a [RFC2822].From A purportedly sends to B with a missing or broken DKIM signature from A 2. B would like to know whether that is an acceptableexpected state of affairs. 4.2. Scenario 2: DKIM Signing Complete State After auditing their outgoing mail and deploying DKIM signing for3. A provides information that it signs all of their legitimateoutgoing mail, a domainbut places no expectation on whether it will arrive with an intact signature. 4. B could be said to be DKIM signing complete. That is, the domain hasuse this information to the best ofbias its ability insuredfilters such that all mail legitimately purportingit looks somewhat more suspicious. 4.2. Problem Scenario 2: Illegitimate Domain Name Use There seems to have comebe a class of mail -- mostly transactional mail from high value domains -- that domain contained a valid DKIM signature. Givenare the likelihoodtarget of signature damage in the current mail infrastructure as noted above, a domain can fitphishing attacks. In particular, many phishing scams forge the DKIM signing complete scenario without wanting[RFC2822].From address in addition to take the risks associated with the more narrow scopespoofing much of use in the previous scenario. A receiver, onthe other hand, may be ablecontent to take advantagetrick unsuspecting users into revealing sensitive information. Domain holders sending this kind of mail would like the knowledge the domain's practice of signing allability to give an enhanced guarantee that mail sent in order to use it to bias filters againsttheir name should always arrive with the unexpected arrivalprovable consent of the domain holder. From a piece of unsigned or damaged in transit mail. 4.3. Scenario 3: Outsourced First Party Signing Many domains do not run their own mail infrastructure, or may outsource parts of it to third parties. It is desirable forreceiver's standpoint, knowing that a domain holder to have the ability delegate to other entities the ability to sign fornot only signs all of its mail, but also expects that legitimate mail from the domain holderwill be received with eithera first partyvalid signature oris quite interesting. This assertion from the equivalent. One obvious use scenariosigning domain is quite a domain holder forbit stronger than the assertion in Problem Scenario 1; even though a small domain that needs to havesigner can never know the ability for their outgoing ISP to sign all of theirtrue path mail on behalf ofwill take before delivery, the domain holder. Other use scenarios include outsourced bulk mail for marketing campaigns, as well as outsourcing various business functions such as insurance benefits, etc. That said, DKIM uses DNS to store selectors. Thus thereimplication is alwaysthat if the ability formessage is lacking a domain holder to delegate allvalid signature the message is either malicious or parts ofis the _domainkey subdomain to a third partyresponsibility of the signing domain holder's choosing. That is,to avoid whatever broke the domain holdersignature. [Informative Note: in terms of a receiving filter, one may be ablechoose to set a NS record for _domainkey.example.com to, say, an email provider who manages that namespace. Theretreat scenario 2 much more harshly than scenario 1; where scenario 1 looks odd, scenario 2 looks like something is also the ability for the domain holder to partition its namespace into subdomainsvery wrong] 1. Mail with a [RFC2822].From A purportedly sends to further constrain how third parties. For example,B with a domain holdermissing or broken DKIM signature from A 2. B would like to know whether that is an expected state of affairs. 3. A provides information that it signs all outgoing mail, but places an expectation that it should arrive with an intact signature, and that the receiver should be suspicious if it does not. 4. B could use this information to bias its filters such that it looks much more suspicious. 4.3. Problem Scenario 3: Domain Sends No Mail A domain may not intend to send mail at all. In such a case, it could be advantageous for a receiver to know the domain's intent and would be likely to treat such mail very suspiciously. It has been noted that a solution to Problem Scenario 2 could potentially be used to emulate this practice. In reality, they are close but not precisely the same semantics. That is, a piece of email purporting to come from a domain which claims to send none is illegitimate on its face, whereas there may be some lingering doubt with Problem Scenario 2 given the possibility in deployments between whether one should publish scenario 1 and 2, etc. 5. SSP Deployment Scenarios Given the problems enumerated above for which we'd like The Protocol to provide information to recipients, there are a number of scenarios that are not related to the problems that are to be solved, per se, but the actual mechanics of implementing/deploying the information service that The Protocol would provide. 5.1. Deployment Scenario 1: Outsourced Signing Many domains do not run their own mail infrastructure, or may outsource parts of it to third parties. It is desirable for a domain holder to have the ability delegate to other entities the ability to sign for the domain holder. One obvious use scenario is a domain holder from a small domain that needs to have the ability for their outgoing ISP to sign all of their mail on behalf of the domain holder. Other use scenarios include outsourced bulk mail for marketing campaigns, as well as outsourcing various business functions such as insurance benefits, etc. 5.2. Deployment Scenario 2: Determinism in Lookup Mechanism The Protocol's client will generally be deployed on incoming mail streams to provide the information as proposed in the problem scenarios. As such, it is envisioned that the RFC2822.From address would be used as a basis for the lookup. In particular, the domain part of the address would be consulted in some manner to fetch the published information. There is a fairly trivial attack against a naive use of this algorithm which is called the subdomain attack: that is, a domain needs to not only _domainkey.benefits.example.compublish a policy for a given DNS label it controls, but it also may need to protect all subdomains of that label as well. If this characteristic is not met, an attacker would need only create a possibly fictitious subdomain which was not covered by The Protocol's information service In widening the scope to have the possibility of all subdomains inherit the parent practice, a number of algorithms could be employed -- all seemingly with their own set of engineering tradeoffs. A common theme in the production of this draft was that the number of lookups, on average should be small, and that the discovery process should always be bound to some small finite number of queries. 5.3. Deployment Scenario 3: Resent Original Mail Resent mail is a third party to constraincommon occurrence in many scenarios in the third partyemail world of today. For example, Alice sends a DKIM signed message with a published practice of signing all messages to Bob's mailing list. Bob, being a good net citizen, wants to onlybe able to produce valid signaturestake his part of the responsibility of the message in question, so he DKIM signs the benefits.example.com subdomain. There have been concerns expressed about how well this would scale whenmessage, perhaps corresponding to the third party is, say, a large ISPSender address. Note that signsthis scenario is completely orthogonal to whether Alice's signature survived Bob's mailing list: Bob merely wants to assert his part in the chain of accountability for thousandsthe benefit of domains. There has been concern about how well thisthe ultimate receivers. It would workbe useful for multiple delegations. Another concern isthis practice to be encouraged as it gives a more accurate view of who handled the message. It also has the side benefit that remailers that are not all DNS providers give the abilityfriendly to specify delegations. Lastly, using NS delegations requires thatDKIM first party signatures (ie, break them) can be potentially assessed by the signer actively cooperate withreceiver based on the domain for whom it is signing. That is,receiver's opinion of the signing domains that actually survived. 5.4. Deployment Scenario 4: Incremental Deployment of Signing As a practical matter, it requiresmay be difficult for a domain to roll out DKIM signing such that they can publish the signer actively manageDKIM Signing Complete practice given the complexities of the user population, outsourced vendors sending on its behalf, etc. This leaves open an exploit that high-value mail such as in Problem Scenario 2 must be classified to the _domainkey delegation forleast common denominator of the domain holder. A domain holderpublished practices. It would not, for example,be abledesirable to makeallow a statement that ISP.com signing on its behalf was acceptable without ISP.com's cooperation. This by extension also appliesdomain holder to other third parties thatpublish a domainlist of exceptions which would have a stronger practices statement. For example, bigbank.example.com might likebe ready to effectively "whitelist" such as mailing listssay that re-sign firstname.lastname@example.org is always signed, but the rest of the domain, say, is not. Another situation is that the domain holder holdspractices of some address local parts in esteem. 4.4. Scenario 4: Resent Original Mail Resent mail isa common occurrence in many scenarios ingiven domain are not the email worldsame as practices of today. For example, Alice sends a DKIM signed message withother local parts. Using the same example of email@example.com being a published practicetransactional kind of signing all messages sent from Alice's domainemail which would like to Bob's mailing listpublish very strong practices, mixed in another domain. Bob, beingwith the rest of the user population local parts which may go through mailing lists, etc, for which a good net citizen, wants toless strong statement is appropriate. It should be ablesaid that DKIM, through the use of subdomains, can already support this kind of differentiation. That is, in order to take his partpublish a strong practice, one only has to segregate those cases into different subdomains. For example: *@accounts.bigbank.example.com would publish a strong practice while *@bigbank.example.com could publish a more permissive practice. 5.5. Deployment Scenario 5: Transport Scenarios Email service provides an any-any mesh of potential connections: all that is required is the responsibilitypublication of an MX record and a SMTP listener to receive mail. Thus the message in question, so he DKIM signs the message. Note that this scenariouse of The Protocol is completely orthogonal to whether Alice's signature survived Bob's mailing list: Bob merely wantslikely to assert his part infall into two main scenarios, the chainfirst of accountabilitywhich are large, well known domains who are in constant contact with one another. In this case caching of records is essential for performance, including the benefitcaching of the ultimate receivers. It would be useful for this practice tonon-existence of records (ie, negative caching). The second main scenario is when a domain exchanges mail with a much smaller volume domain. This scenario can be encouragedboth perfectly normal as it gives a more accurate view of who handled the message, andwith the trustworthinesscase of vanity domains, and sadly a vector for those sending mail for anti-social reasons. In this case we'd like the handlers. It also has the side benefit that remailers that are not friendlyburden to The Protocol querier to DKIM first party signatures (ie, break them) can stillbe potentially assessed by the receiver based on the receiver's opinionlow, since many of the signing domains that actually survived. 4.5. Scenario 5: Incremental Deployment of Signing Aslookups will not provide a practical matter,useful answer. Likewise, it maywould be difficult foradvantageous to have upstream caching here as well so that, say, a mailing list exploder on a small domain to roll out DKIM signing such that they can publish the DKIM Signing Complete practice for its given the complexitiesdoes not result in an explosion of queries back at the user population, outsourced vendors sending on its behalf, etc. This leaves open an exploit that high-value mail must be classified toroot server for the least common denominatorsmall domain. 5.6. Deployment Scenario 6: Human Legibility of Practices While The Protocol records are likely to be primarily consumed by an automaton, for the published practices.foreseeable future they are also likely to be inspected by hand. It would be desirable to allow a domain holdernice to publish a list of exceptions which wouldhave a stronger practices statement. In this situation, bigbank.example.com might be ready to say that firstname.lastname@example.org is always signed, but the rest of the domain, say, is not. Another situation is thatthe practices of some address local partsstated in a given domainfashion which is also intuitive to the human inspectors. [Author's $.02: it's been amply demonstrated that simple human readable labels are notoften misconstrued. Opaque symbols do have the same as practices of other local parts. Usingadvantage that you need to consult the same example of email@example.com being a transactional kind of email which would likedefinition to publish very strong practices, mixed indetermine its meaning rather than just intuiting what it "ought" to mean. /mat] 5.7. Deployment Scenario 7: Cryptographic Downgrade Attacks There is a downgrade attack possible where a DKIM signature is hashed with the rest of the user population local parts which may go through mailing lists, etc, for whicha less strong statementpreviously acceptable but now insecure hash algorithm. This could allow attackers to send their chosen text which is appropriate.apparently signed by the targeted domain. It shouldwould be said that DKIM, through the use of subdomains, can already support this kind of differentiation. That is, in orderadvantageous for a domain to publish a strong practice, onewhat the allowable signing/hashing algorithms are to prevent this downgrade attack. 5.8. Deployment Scenario 8: Extensibility While this document pertains only hasto segregate those cases into different subdomains. For example: *@accounts.bigbank.example.comrequirements surrounding DKIM signing practices, it would publishbe beneficial for the protocol to be able to extend to other protocols. 5.9. Deployment Scenario 9: Security The protocol must be able to withstand life in a hostile open internet environment. These include DoS attacks, and especially DoS attacks that leverage themselves through amplification inherent in the protocol. In addition, while a useful protocol may be built without strong practice while *@bigbank.example.com could publishsource authentication provided by the information service, a more permissive practice. 5.path to strong source authentication should be provided by the protocol, or underlying protocols. 6. Requirements This section defines the requirements for The Protocol. As with most requirements drafts, these requirements define the MINIMUM requirements that a candidate protocol must provide. It should also be noted that The Protocol must fulfill all of the requirements. [Informative Note: it's not clear to the author that all of the provisional requirements can fulfill the harder requirements. If this is determined to be true, the provisional requirement should either be dropped or the harder requirements revised] 5.1. Discovery Requirements 1. Discovery mechanism MUST be rooted in DNS. 2. Discovery mechanism MUST converge in a deterministic number of exchanges. [Informative Note: this, for all intents and purposes is a prohibition on anything that might produce loops; also though "deterministic" doesn't specify how many exchanges, the expectation is "few".] 3. Discovery mechanism MUST NOT overload semantics of existing DNS resource records where name space collisions are plausible. For the purposes of this requirement, neither an underscore prefixed namespace nor a new resource record type are considered plausible. 5.2. Transport requirements 1. Widespread deployment of the transport layer would be highly desirable, especially if riding on top of a true transport layer (eg, TCP, UDP). 2. A low-cost query/response in terms of latency time and the number of packets involved is highly desirable. 3. If the infrastructure doesn't provide caching (ala DNS), the records retrieved will need time-to-live values to allow querying verifiers to maintain their own caches. Existing caching infrastructure is, however, highly desirable. 4. Multiple geographically and topologically diverse servers must be supported for high availability 5.3. Practice and Expectation Requirements In this section, a Practice is defined as a true statement according to the [RFC2822].From domain holder of its intended externally viewable behavior. An Expectation combines with a Practice to convey what the domain holder considersbe true, the likely outcome ofprovisional requirement should either be dropped or the survivabilityharder requirements revised] 6.1. Discovery Requirements Receivers need a means of the Practice atobtaining information about a receiver. For example,sender's DKIM practices. This requires a Practice that X is true when it leavesmeans of discovering where the domain,information is and an Expectation thatwhat it will|will-not|may|may-not remain true for some/all receivers.contains. 1. The Protocol MUST be able to make Practices and Expectation assertions aboutauthor is the [RFC2822].From addressfirst-party sender of a message, as specified in the context of DKIM.[rfc2822].From field. The Protocol will not make assertions about other addresses for DKIM at this time. 2. The Protocol MUST be able to publish a Practice thatProtocol's information is associated with the author's domain doesn't send mail. 3. The Protocol MUST be ablename and is published subordinate to publish a Practicethat domain name. 2. In order to limit the domain's signing behavior is "DKIM Signing Complete" 4.cost of its use, any query service supplying The Protocol MUST be able to publish an Expectation thatProtocol's information must provide a verifiable First Party DKIM Signature should be expected on receipt ofdefinitive responsive within a message.small, deterministic number of query exchanges. [Informative Note: the DKIM Signing Complete Practice seems to be a pre-requisite for this Expectation] 5. [PROVISIONAL] A domain MUST be able to delegate responsibilitythis, for signing its messages to a non-related domain in suchall intents and purposes is a wayprohibition on anything that it does not require active participation by the non-related domain. That is,might produce loops or result in extended delays and overhead; also though "deterministic" doesn't specify how many exchanges, the published informationexpectation is "few".] [Refs: Deployment Scenario 2] 3. The Protocol's publishing mechanism MUST have a waybe defined to specify the domains that are allowedproduce unambiguous semantics, particularly with respect to sign on its behalf. 5.3.1. Negative Commentary 1. Scaling Concerns for DNS: the addition of third party signers begs the question of how thatother information is stored in the DNS ifthat ismight share the repository (which seems pretty likely). The naive approachpublication mechanism. [Informative note: An example of just encoding them into oneambiguity is sharing resource record could quite plausiblely exceed the maximumtypes within a common DNS UDP MTU whichleaf. Hence, uniquely defined leaf names or uniquely defined resource record types will ensure unambiguous reference.] [Refs: Deployment Scenario 2] 6.2. Transport requirements 1. Widespread deployment of the transport layer would be highly undesirable. Other approaches have been suggested, but they seemingly trade off complexity, numberdesirable, especially if riding on top of lookups, non-deterministic completion, etc.a true transport layer (eg, TCP, UDP). [Refs: Deployment Scenario 5, 8] 2. Alternate mechanism to NS delegation,A low-cost query/response in terms of latency time and threats not well understood:the mechanism for delegating zones within DNS is a very well understood problem which well understood threats. The threats involved with another formnumber of indirection are far less clear, though undoubtably present. Therepackets involved is a great deal of concern that (re)discovering those threats, deciding whether they are valid, whether theyhighly desirable. [Refs: Deployment Scenario 5] 3. If the infrastructure doesn't provide caching (ala DNS), the records retrieved will need time-to-live values to mitigated, etc, etc are a worthwhile exercise given that this provides minimal functionality over what currently exists with DKIM base. 3. The seemsallow querying verifiers to maintain their own caches. Existing caching infrastructure is, however, highly desirable. [Refs: Deployment Scenario 5] 4. Multiple geographically and topologically diverse servers must be a strong consensussupported for most of requirements,high availability [Refs: Deployment Scenario 5, 8] 6.3. Practice and quiteExpectation Requirements In this section, a bit less for this,Practice is there harm if we don't do this now? That is, can it extended later if needed based on much more experience? 4. Concerns about conflation of responsibility and/or reputation: there are concernsdefined as a true statement according to the [RFC2822].From domain holder of addingits intended externally visible behavior. An Expectation combines with a Practice to convey what the confusion about who is taking responsibility for what. Is it the d=domain inholder considers the DKIM-signature? Is itlikely outcome of the domain insurvivability of the From: address? Is it both? IsPractice for a receiver. For example, a Practice that X is true when it neither? Keeping this simple by usingleaves the NS delegation mechanism would not raise these interesting, if not thorny questions. 5. It's not cleardomain, and an Expectation that this requirement actually delivers onit will|will-not|may|may-not remain true for some/all receivers. 1. The Protocol MUST be able to make Practices and Expectation assertions about the less complexity aspect of its billing: one of[RFC2822].From address in the attractionscontext of DKIM. The Protocol will not make assertions about other addresses for DKIM at this requirementtime. [Refs: Problem Scenario 1,2] 2. [PROVISIONAL] The Protocol MUST be able to publish a Practice which is indicative that theredomain doesn't send mail. [Refs: Problem Scenario 3] 3. If the Discovery process would be littleshortened by publication of a "null" practice, the protocol SHOULD provide a mechanism to publish such a practice. [INFORMATIVE NOTE: there seems to be widespread consensus that a "neutral" or no interaction required between"I sign some mail" practice is useless to receivers. However, a null practice may help to cut short the first partypolicy lookup mechanism if it's published, and if that's the designated third party signer. Given the security issues with this approach,case it is not clear that the interaction required betweenseems worthwhile. Also, a null policy may have some forensic utility, such as gaging the first and third parties are any less onerous. 6. Security Threat withnumber of domains considering/using DKIM base, a first party signer can always clarify which address it isfor example.] [Refs: Deployment Scenario 2] 4. The Protocol MUST be able to publish a Practice that the domain's signing behavior is "DKIM Signing Complete" [Refs: Problem Scenario 1] 5. The Protocol MUST be able to publish an Expectation that a verifiable First Party DKIM Signature should be expected on behalfreceipt of by using the i= tag. That is, when there's ambiguity between, say, From:a message. [Refs: Problem Scenario 2] 6. Practices and Sender: the signer hasExpectations MUST be presented in the abilityProtocol syntax using as intuitive a descriptor as possible. For example, p=? would be better represented as p=unknown. [Refs: Deployment Scenario 6] 7. The Protocol MUST NOT invent a different means of allowing affiliated parties to clarify which address the signature wassign on behalf of if it so desires. Fora third party signature,domain's behalf. Because DKIM uses DNS to store selectors, there is no clarity since the signature by definition has no relationship toalways the origination addresses. A legitimate flow follows: - An ISP signsability for both a.com and mailinglist.com - mailinglist.com sendsa piece of mail From: firstname.lastname@example.org, Sender: email@example.com - ISP signs the message with d=ISP.com - The receiver at this point has no idea who ISP.com was signing on behalfdomain holder to delegate all or parts of because they are both legitimately signed by ISP.com The attack is essentially identical: it only requires that mailinglist.com spoofthe From: address_domainkey subdomain to whatever other customeran affiliated party of ISP.com.the domain holder's choosing. That is, mailinglist.com canthe domain holder may be any example.com with bad intentions. Worse, isable to set a NS record for _domainkey.example.com to, say, an email provider who manages that namespace. There is also the ISP will ordinarily have no clue asability for the domain holder to whetherpartition its customers are running mailing lists or not, so it would not havenamespace into subdomains to further constrain how third parties. For example, a domain holder could delegate only _domainkey.benefits.example.com to a third party to constrain the third party to only be able to produce valid signatures in the ability "legitimate" From: spoofing (ie,benefits.example.com subdomain. Last, a real mailing list) from illegitimate spoofing. 6.domain holder can even use CNAME's to delegate individual leaf nodes. 8. [PROVISIONAL] The protocol MUST have the ability to provide practices and expecationsexpectations keyed off of the local part of the [RFC2822].From address. As with all provisional requirements, this requirement must not be in conflict with other requirements, including DNS considerations, etc. [INFORMATIVE NOTE: this requirement seems to have rather weak support. It's mainly been added so that it can be issue- tracked. /mat] 7.[Refs: Deployment Scenario 4] 9. Practices and Expectations MUST be presented as an information service from the sendersigning domain to be consumed as an added factor to the receiver's local policy. In particular, a Practice or Expectation MUST NOT mandate any disposition stance on the receiver. 8. If the Discovery process would be shortened by publication of a "null" practice, the protocol SHOULD provide a mechanism to publish such a practice. [INFORMATIVE NOTE: there seems to be widespread consensus that a "neutral" or "I sign some mail" practice is useless to receivers. However, a null practice may help to cut short the policy lookup mechanism if it's published, and if that the case it seems worthwhile. Also, a null policy may have some forensic utility, such as gaging the number of domains considering/using DKIM for example.] 9.[Refs: Problem Scenario 1, 2, 3] 10. There is no requirement that The Protocol publish a Practices of any/all third parties that MUST NOT sign on the domain holder's behalf. This should be considered out of scope. [INFORMATIVE NOTE: this is essentially saying that the protocol doesn't have to concern itself with being a blacklist repository.] 10.[Refs: Problem Scenario 1-2] 11. The Protocol MUST NOT be required to be invoked if a valid first party signature is found. 11.[Refs: Deployment Scenario 2] 12. [PROVISIONAL] A domain holder MUST be able to publish a Practice which enumerates the acceptable cryptographic algorithms for signatures purportedly from that domain. [INFORMATIVE NOTE: this is to counter a bid down attack; some comments indicated that this need only be done if the algorithm was considered suspect by the receiver; I'm not sure that I've captured that nuance correctly] 12. Given the considerations in scenario 4, the[Refs: Deployment Scenario 7] 13. The protocol MUST NOT provide a mechanism which impugns the mereexistence of thirdnon-first party signatures in a message. A corrolarycorollary of this requirement is that the protocol MUST NOT in any way tielink practices of first party signers with the practices of third party signers. [INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not restatemeddle in what is ultimately the local policy of the receiver.] 5.4.[Refs: Deployment Scenario 3] 6.4. Extensibility and Forward CompatibiltyCompatibility Requirements 1. The Protocol MUST NOT extend to any other protocol than DKIM for email at this time. The Protocol SHOULD be able to extend for protocols other than DKIM. [Refs: Deployment Scenario 8] 2. The Protocol MUST be able to add new Practices and Expectations within the existing discovery/transport/practices in a backward compatible fashion. 3. [PROVISIONAL] The Protocol MUST be able to extend for new protocols signed by DKIM 4. [PROVISIONAL] The Protocol MUST be able to extend for protocols other than DKIM 6.[Refs: Deployment Scenario 8] 7. Security Requirements 1. Minimize DoS potential: The Protocol for a high-value domain is potentially a high-value DoS target, especially since the unavailability of The Protocol's record could make unsigned messages less suspicious. 2. Amplification Attacks: The Protocol MUST NOT make highly leveraged amplification or make-work attacks possible. In particular any amplification must be O(1). [Author's question: is it really O(1)? or O(n)?] [Refs: Deployment Scenario 9] 3. Authenticity: The Protocol MUST have the ability for a domain holder to provide The Protocol's data such that a receiver can determine that it is authentically from the domain holder with a large degree of certainty. The Protocol may provide means which provide less certainty in trade off for ease of deployment. 7.[Refs: Deployment Scenario 9] 8. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 8.9. Security Considerations This draft defines requirements for a new protocol and the security related requirements are defined above. There is an expectation that The Protocol will not always be required to have source authentication of the practices information which is noteworthy. 9. Acknowledgements still free10. Acknowledgments Due to goodflipping in the market and raising interest rates, this home 10.is no longer free. Dave Crocker and Jim Fenton helped me raise the walls on this draft and are accorded a room at the inn. The inn is not yet full, however. 11. References 10.1.11.1. Normative References [I-D.ietf-dkim-base] Allman, E., "DomainKeys Identified Mail (DKIM) Signatures", draft-ietf-dkim-base-04 (work in progress), July 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 10.2.11.2. Informative References [I-D.ietf-dkim-overview] Hansen, T., "DomainKeys Identified Mail (DKIM) Service Overview", draft-ietf-dkim-overview-01 (work in progress), June 2006. [I-D.ietf-dkim-threats] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work in progress), May 2006. Author's Address Michael Thomas Cisco Systems 606 Sanchez St San Francisco, California 94114 USA Phone: +1-408-525-5386 Fax: +1-408-525-5386 Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).