Requirements for Open Pluggable Edge Services (OPES) Callout Protocols
RFC 3836
| Document | Type | RFC - Informational (August 2004) | |
|---|---|---|---|
| Authors | Andre Beck , Reinaldo Penno , Hilarie Orman , Markus Hofmann , Andreas Terzis | ||
| Last updated | 2015-10-14 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Ned Freed | |
| Send notices to | (None) |
RFC 3836
Network Working Group M. Thomas
Request for Comments: 5016 Cisco Systems
Category: Informational October 2007
Requirements for a
DomainKeys Identified Mail (DKIM) Signing Practices Protocol
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism
for domains to assert responsibility for the messages they handle. A
related mechanism will allow an administrator to publish various
statements about their DKIM signing practices. This document defines
requirements for this mechanism, distinguishing between those that
must be satisfied (MUST), and those that are highly desirable
(SHOULD).
Thomas Informational [Page 1]
RFC 5016 DKIM-SSP-REQ October 2007
Table of Contents
1. Introduction ....................................................2
2. Definitions and Requirements Language ...........................3
3. SSP Problem Scenarios ...........................................4
3.1. Problem Scenario 1: Is All Mail Signed with DKIM? ..........4
3.2. Problem Scenario 2: Illegitimate Domain Name Use ...........5
4. SSP Deployment Considerations ...................................6
4.1. Deployment Consideration 1: Outsourced Signing .............6
4.2. Deployment Consideration 2: Subdomain Coverage .............6
4.3. Deployment Consideration 3: Resent Original Mail ...........7
4.4. Deployment Consideration 4: Incremental Deployment
of Signing .................................................7
4.5. Deployment Consideration 5: Performance and Caching ........8
4.6. Deployment Consideration 6: Human Legibility of Practices ..8
4.7. Deployment Consideration 7: Extensibility ..................8
4.8. Deployment Consideration 8: Security .......................8
5. Requirements ....................................................9
5.1. Discovery Requirements .....................................9
5.2. SSP Transport Requirements ................................10
5.3. Practice and Expectation Requirements .....................10
5.4. Extensibility and Forward Compatibility Requirements ......13
6. Requirements for SSP Security ..................................13
7. Security Considerations ........................................13
8. Acknowledgments ................................................13
9. References .....................................................14
9.1. Normative References ......................................14
1. Introduction
DomainKeys Identified Mail [RFC4871] defines a message level signing
and verification mechanism for email. While a DKIM signed message
speaks for itself, there is ambiguity if a message doesn't have a
valid first party signature (i.e., on behalf of the [RFC2822].From
address): is this to be expected or not? For email, this is an
especially difficult problem since there is no expectation of a
priori knowledge of a sending domain's practices. This ambiguity can
be used to mount a bid down attack that is inherent with systems like
email that allow optional authentication: if a receiver doesn't know
otherwise, it should not assume that the lack of a valid signature is
exceptional without other information. Thus, an attacker can take
advantage of the ambiguity and simply not sign messages. 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 an unsigned piece of email.
Thomas Informational [Page 2]
RFC 5016 DKIM-SSP-REQ October 2007
This document defines the requirements for a mechanism that permits
the publication of Sender Signing Practices (SSP). The document is
organized into two main sections: first, a Problem and Deployment
Scenario section that describes the problems that SSP is intended to
address as well as the deployment issues surrounding the base
problems, and the second section is the Requirements that arise
because of those scenarios.
2. Definitions and Requirements Language
o Domain Holder: the entity that 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 signing identity (the d= tag or the more
specific identity i= tag) matches the first party address.
"Matches" in this context is defined in [RFC4871].
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 is not required to correspond to
a header field address such as the contents of Sender or List-Id,
etc.
o Practice: a statement according to the [RFC2822].From domain
holder of externally verifiable behavior in the email messages it
sends.
o Expectation: an expectation combines with a practice to convey
what the domain holder considers the likely survivability of the
practice for a receiver, in particular receivers that may be more
than one SMTP hop away.
o DKIM Signing Complete: a practice where the domain holder asserts
that all legitimate mail will be sent with a valid first party
signature.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", &RFC 3836 Requirements for OPES Callout Protocols August 2004
capabilities, such as the fail-over behavior, MAY be negotiated
between the two endpoints independently of callout connections.
The parties to a callout protocol MAY use callout connections to
negotiate all or some of their capabilities and parameters.
Alternatively, a separate control connection MAY be used for this
purpose.
3.13. Meta Data and Instructions
The OPES callout protocol MUST provide a mechanism for the endpoints
of a particular callout transaction to include metadata and
instructions for the OPES processor or callout server in callout
requests and responses.
Specifically, the callout protocol MUST enable an OPES processor to
include information about the forwarded application message in a
callout request, e.g. in order to specify the type of forwarded
application message or to specify what part(s) of the application
message are forwarded to the callout server. Likewise, the callout
server MUST be able to include information about the returned
application message.
The OPES processor MUST further be able to include an ordered list of
one or more uniquely specified OPES services which are to be
performed on the forwarded application message in the specified
order. However, as the callout protocol MAY also choose to associate
callout connections with specific OPES services, there may not be a
need to identify OPES services on a per-callout transaction basis.
Additionally, the OPES callout protocol MUST allow the callout server
to indicate to the OPES processor the cacheability of callout
responses. This implies that callout responses may have to carry
cache-control instructions for the OPES processor.
The OPES callout protocol MUST further enable the OPES processor to
indicate to the callout server if it has kept a local copy of the
forwarded application message (or parts thereof). This information
enables the callout server to determine whether the forwarded
application message must be returned to the OPES processor, even if
it has not been modified by an OPES service.
The OPES callout protocol MUST also allow OPES processors to comply
with the tracing requirements of the OPES architecture as laid out in
[1] and [3]. This implies that the callout protocol MUST enable a
callout server to convey to the OPES processor information about the
OPES service operations performed on the forwarded application
message.
Beck, et al. Informational [Page 8]
RFC 3836 Requirements for OPES Callout Protocols August 2004
4. Performance Requirements
4.1. Protocol Efficiency
The OPES callout protocol SHOULD have minimal latency. For example,
the size and complexity of its headers could be minimized.
Because OPES callout transactions add latency to application protocol
transactions on the data path, callout protocol efficiency is crucial
to overall performance.
5. Security Requirements
In the absence of any security mechanisms, sensitive information
might be communicated between the OPES processor and the callout
server in violation of either endpoint's security and privacy policy,
through misconfiguration or deliberate insider attack. By using
strong authentication, message encryption, and integrity checks, this
threat can be minimized to a smaller set of insiders and/or operator
configuration errors.
The OPES processor and the callout servers SHOULD have enforceable
policies that limit the parties they communicate with and that
determine the protections to use based on identities of the endpoints
and other data (such as enduser policies). In order to enforce the
policies, they MUST be able to authenticate the callout protocol
endpoints using cryptographic methods.
5.1. Authentication, Confidentiality, and Integrity
The parties to the callout protocol MUST have a sound basis for
binding authenticated identities to the protocol endpoints, and they
MUST verify that these identities are consistent with their security
policies.
The OPES callout protocol MUST provide for message authentication,
confidentiality, and integrity between the OPES processor and the
callout server. It MUST provide mutual authentication. For this
purpose, the callout protocol SHOULD use existing security
mechanisms. The callout protocol specification is not required to
specify the security mechanisms, but it MAY instead refer to a
lower-level security protocol and discuss how its mechanisms are to
be used with the callout protocol.
Beck, et al. Informational [Page 9]
RFC 3836 Requirements for OPES Callout Protocols August 2004
5.2. Hop-by-Hop Confidentiality
If hop-by-hop encryption is a requirement for the content path, then
this confidentiality MUST be extended to the communication between
the OPES processor and the callout server. While it is recommended
that the communication between the OPES processor and callout server
always be encrypted, encryption MAY be optional if both the OPES
processor and the callout server are co-located together in a single
administrative domain with strong confidentiality guarantees.
In order to minimize data exposure, the callout protocol MUST use a
different encryption key for each encrypted content stream.
5.3. Operation Across Untrusted Domains
The OPES callout protocol MUST operate securely across untrusted
domains between the OPES processor and the callout server.
If the communication channels between the OPES processor and callout
server cross outside of the organization which is responsible for the
OPES services, then endpoint authentication and message protection
(confidentiality and integrity) MUST be used.
5.4. Privacy
Any communication carrying information relevant to privacy policies
MUST protect the data using encryption.
6. Security Considerations
The security requirements for the OPES callout protocol are discussed
in Section 5.
7. References
7.1. Normative References
[1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An
Architecture for Open Pluggable Edge Services (OPES)", RFC 3835,
August 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
Beck, et al. Informational [Page 10]
RFC 3836 Requirements for OPES Callout Protocols August 2004
[4] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
7.2. Informative References
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003.
8. Acknowledgments
Parts of this document are based on previous work by Anca Dracinschi
Sailer, Volker Hilt, and Rama R. Menon.
The authors would like to thank the participants of the OPES WG for
their comments on this document.
Beck, et al. Informational [Page 11]
RFC 3836 Requirements for OPES Callout Protocols August 2004
9. Authors' Addresses
Andre Beck
Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733
US
EMail: abeck@bell-labs.com
Markus Hofmann
Lucent Technologies
Room 4F-513
101 Crawfords Corner Road
Holmdel, NJ 07733
US
Phone: +1 732 332 5983
EMail: hofmann@bell-labs.com
Hilarie Orman
Purple Streak Development
EMail: ho@alum.mit.edu
URI: http://www.purplestreak.com
Reinaldo Penno
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
US
EMail: rpenno@nortelnetworks.com
Andreas Terzis
Computer Science Department
Johns Hopkins University
3400 North Charles Street, 224 NEB
Baltimore, MD 21218
Phone: +1 410 516 5847
EMail: terzis@cs.jhu.edu
Beck, et al. Informational [Page 12]
RFC 3836 Requirements for OPES Callout Protocols August 2004
quot;MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Thomas Informational [Page 3]
RFC 5016 DKIM-SSP-REQ October 2007
3. SSP Problem Scenarios
The email world is a diverse place with many deployment
considerations. This section outlines expected usage scenarios where
DKIM signing/verifying will take place, and how a new protocol might
help to clarify the relevance of DKIM-signed mail.
3.1. Problem Scenario 1: Is All Mail Signed with DKIM?
After auditing their outgoing mail and deploying DKIM signing for all
of their legitimate outgoing mail, a domain could be said to be DKIM
signing complete. That is, the domain has, to the best of its
ability, ensured that all legitimate mail purporting to have come
from that domain contains a valid DKIM signature.
A receiver in the general case doesn't know what the practices are
for a given domain. Thus, the receiver is at a disadvantage in not
knowing whether or not it should expect all mail to be signed from a
given domain. 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 that allows a receiver to query for the
practices and expectations of the first party domain when no valid
first party signature is found could be useful in 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, unrestricted use patterns of
mail (e.g., where users may be members of mailing lists, etc.) will
likely suffer occasional, non-malicious signature failure in transit.
While probably not a large percentage of total traffic, this kind of
breakage may be a significant concern for those usage patterns. This
scenario defines where the sender cannot set any expectation as to
whether an individual message will arrive intact.
Even without that expectation, a receiver may be able to take
advantage of the knowledge that the domain's practice is to sign all
mail and bias its 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.
Thomas Informational [Page 4]
RFC 5016 DKIM-SSP-REQ October 2007
The following exchange illustrates problem scenario 1.
1. Mail with a [RFC2822].From domain Alice is sent to domain Bob
with a missing or broken DKIM first party signature from Alice.
2. Domain Bob would like to know whether that is an expected state
of affairs.
3. Domain Alice provides information that it signs all outgoing
mail, but places no expectation on whether it will arrive with an
intact first party signature.
4. Domain Bob could use this information to bias its filters to
examine the message with some suspicion.
3.2. Problem Scenario 2: Illegitimate Domain Name Use
A class of mail typified by transactional mail from high-value
domains is currently the target of phishing attacks. In particular,
many phishing scams forge the [RFC2822].From address in addition to
spoofing much of the content to trick unsuspecting users into
revealing sensitive information. Domain holders sending this mail
would like the ability to give an enhanced guarantee that mail sent
with their domain name should always arrive with the proof that the
domain holder consented to its transmission. That is, the message
should contain a valid first party signature as defined above.
From a receiver's standpoint, knowing that a domain not only signs
all of its mail, but places a very high value on the receipt of a
valid first party signature from that domain is helpful. Hence, a
receiver knows that the sending domain signs all its mail, and that
the sending domain considers mail from this domain particularly
sensitive in some sense, and is asking the receiver to be more
suspicious than it otherwise might be of a broken or missing first-
party signature. A receiver with the knowledge of the sender's
expectations in hand might choose to process messages not conforming
to the published practices in a special manner. Note that the
ability to state an enhanced guarantee of a valid signature means
that senders should expect mail that traverses modifying
intermediaries (e.g., mailing lists, etc.) will likely be quarantined
or deleted; thus, this scenario is more narrow than problem scenario
1.
Informative Note: a receiving filter may choose to treat scenario
2 much more harshly than scenario 1; where scenario 1 looks odd,
scenario 2 looks like something is very wrong.
Thomas Informational [Page 5]
RFC 5016 DKIM-SSP-REQ October 2007
1. Mail with a [RFC2822].From domain Alice is sent to domain Bob
with a missing or broken first party DKIM signature from domain
Alice.
2. Domain Bob would like to know whether that is an expected state
of affairs.
3. Domain Alice provides information that it signs all outgoing
mail, and furthermore places an expectation that it should arrive
with an intact first party signature, and that the receiver
should be much more wary if it does not.
4. Domain Bob could use this information to bias its filters such
that it examines the message with great suspicion.
4. SSP Deployment Considerations
Given the problems enumerated above for which we'd like SSP 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 SSP would provide.
4.1. Deployment Consideration 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 to 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.
4.2. Deployment Consideration 2: Subdomain Coverage
An SSP client will perform lookups on incoming mail streams to
provide the information as proposed in the problem scenarios. The
domain part of the first address of the [RFC2822].From will form the
basis to fetch the published information. A trivial attack to
circumvent finding the published information can be mounted by simply
using a subdomain of the parent domain that doesn't have published
information. This attack is called the subdomain attack: that is, a
domain wants to not only publish a policy for a given DNS label it
controls, but it would also like 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 that was not covered
Thomas Informational [Page 6]
RFC 5016 DKIM-SSP-REQ October 2007
by the SSP's information service. Thus, it would be advantageous for
SSP to not only cover a given domain, but all subdomains of that
domain as well.
4.3. Deployment Consideration 3: Resent Original Mail
Resent mail is a common occurrence in many scenarios in the email
world of today. For example, domain Alice sends a DKIM-signed
message with a published practice of signing all messages to domain
Bob's mailing list. Bob, being a good net citizen, wants to be able
to take his part of the responsibility of the message in question, so
he DKIM signs the message, perhaps corresponding to the Sender
address.
Note that this 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 the benefit of the ultimate
receivers. It would be useful for this 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 break DKIM first party
signatures can be potentially assessed by the receiver based on the
receiver's opinion of the signing domains that actually survived.
4.4. Deployment Consideration 4: Incremental Deployment of Signing
As a practical matter, it may be difficult for a domain to roll out
DKIM signing such that they can publish the DKIM Signing Complete
practice given the complexities of the user population, the
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 least common denominator of the published
practices. It would be desirable to allow a domain holder to publish
a list of exceptions that would have a more restrictive practices
statement. NB: this consideration has been deemed met by the
mechanisms provided by the base DKIM signing mechanism; it is merely
documented here as having been an issue.
For example, bigbank.example.com might be ready to say that
statements@bigbank.example.com is always signed, but the rest of the
domain, say, is not. Another situation is that the practices of some
address local parts in a given domain are not the same as practices
of other local parts. Using the same example of
statements@bigbank.example.com being a transactional kind of email
that would like to publish very strong practices, mixed in with the
rest of the user population local parts, which may go through mailing
lists, etc., for which a less strong statement is appropriate.
Thomas Informational [Page 7]
RFC 5016 DKIM-SSP-REQ October 2007
It should be said that DKIM, through the use of subdomains, can
already support this kind of differentiation. That is, in order to
publish a strong practice, one only has to segregate those cases into
different subdomains. For example: accounts.bigbank.example.com
would publish constrained practices, while
corporateusers.bigbank.example.com might publish more permissive
practices.
4.5. Deployment Consideration 5: Performance and Caching
Email service provides an any-any mesh of potential connections: all
that is required is the publication of an MX record and an SMTP
listener to receive mail. Thus, the use of SSP is likely to fall
into two main scenarios, the first of which are large, well-known
domains that are in constant contact with one another. In this case,
caching of records is essential for performance, including the
caching of the non-existence of records (i.e., negative caching).
The second main scenario is when a domain exchanges mail with a much
smaller volume domain. This scenario can be both perfectly normal as
with the case of vanity domains, and unfortunately, a vector for
those sending mail for anti-social reasons. In this case, we'd like
the message exchange burden to SSP querier to be low, since many of
the lookups will not provide a useful answer. Likewise, it would be
advantageous to have upstream caching here as well so that, say, a
mailing list exploder on a small domain does not result in an
explosion of queries back at the root and authoritative server for
the small domain.
4.6. Deployment Consideration 6: Human Legibility of Practices
While SSP records are likely to be primarily consumed by an
automaton, for the foreseeable future they are also likely to be
inspected by hand. It would be nice to have the practices stated in
a fashion that is also intuitive to the human inspectors.
4.7. Deployment Consideration 7: Extensibility
While this document pertains only to requirements surrounding DKIM
signing practices, it would be beneficial for the protocol to be able
to extend to other protocols.
4.8. Deployment Consideration 8: Security
SSP 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
Thomas Informational [Page 8]10. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Beck, et al. Informational [Page 13]