7Network Working Group M. Thomas
8Request for Comments: 5016 Cisco Systems
9Category: Informational October 2007
13 DomainKeys Identified Mail (DKIM) Signing Practices Protocol
17 This memo provides information for the Internet community. It does
18 not specify an Internet standard of any kind. Distribution of this
23 DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism
24 for domains to assert responsibility for the messages they handle. A
25 related mechanism will allow an administrator to publish various
26 statements about their DKIM signing practices. This document defines
27 requirements for this mechanism, distinguishing between those that
28 must be satisfied (MUST), and those that are highly desirable
58Thomas Informational [Page 1]
60RFC 5016 DKIM-SSP-REQ October 2007
65 1. Introduction ....................................................2
66 2. Definitions and Requirements Language ...........................3
67 3. SSP Problem Scenarios ...........................................4
68 3.1. Problem Scenario 1: Is All Mail Signed with DKIM? ..........4
69 3.2. Problem Scenario 2: Illegitimate Domain Name Use ...........5
70 4. SSP Deployment Considerations ...................................6
71 4.1. Deployment Consideration 1: Outsourced Signing .............6
72 4.2. Deployment Consideration 2: Subdomain Coverage .............6
73 4.3. Deployment Consideration 3: Resent Original Mail ...........7
74 4.4. Deployment Consideration 4: Incremental Deployment
75 of Signing .................................................7
76 4.5. Deployment Consideration 5: Performance and Caching ........8
77 4.6. Deployment Consideration 6: Human Legibility of Practices ..8
78 4.7. Deployment Consideration 7: Extensibility ..................8
79 4.8. Deployment Consideration 8: Security .......................8
80 5. Requirements ....................................................9
81 5.1. Discovery Requirements .....................................9
82 5.2. SSP Transport Requirements ................................10
83 5.3. Practice and Expectation Requirements .....................10
84 5.4. Extensibility and Forward Compatibility Requirements ......13
85 6. Requirements for SSP Security ..................................13
86 7. Security Considerations ........................................13
87 8. Acknowledgments ................................................13
88 9. References .....................................................14
89 9.1. Normative References ......................................14
93 DomainKeys Identified Mail [RFC4871] defines a message level signing
94 and verification mechanism for email. While a DKIM signed message
95 speaks for itself, there is ambiguity if a message doesn't have a
96 valid first party signature (i.e., on behalf of the [RFC2822].From
97 address): is this to be expected or not? For email, this is an
98 especially difficult problem since there is no expectation of a
99 priori knowledge of a sending domain's practices. This ambiguity can
100 be used to mount a bid down attack that is inherent with systems like
101 email that allow optional authentication: if a receiver doesn't know
102 otherwise, it should not assume that the lack of a valid signature is
103 exceptional without other information. Thus, an attacker can take
104 advantage of the ambiguity and simply not sign messages. If a
105 protocol could be developed for a domain to publish its DKIM signing
106 practices, a message verifier could take that into account when it
107 receives an unsigned piece of email.
114Thomas Informational [Page 2]
116RFC 5016 DKIM-SSP-REQ October 2007
119 This document defines the requirements for a mechanism that permits
120 the publication of Sender Signing Practices (SSP). The document is
121 organized into two main sections: first, a Problem and Deployment
122 Scenario section that describes the problems that SSP is intended to
123 address as well as the deployment issues surrounding the base
124 problems, and the second section is the Requirements that arise
125 because of those scenarios.
1272. Definitions and Requirements Language
129 o Domain Holder: the entity that controls the contents of the DNS
130 subtree starting at the domain, either directly or by delegation
131 via NS records it controls.
133 o First Party Address: for DKIM, a first party address is defined to
134 be the [RFC2822].From address in the message header; a first party
135 address is also known as an Author address.
137 o First Party Signature: a first party signature is a valid
138 signature where the signing identity (the d= tag or the more
139 specific identity i= tag) matches the first party address.
140 "Matches" in this context is defined in [RFC4871].
142 o Third Party Signature: a third party signature is a valid
143 signature that does not qualify as a first party signature. Note
144 that a DKIM third party signature is not required to correspond to
145 a header field address such as the contents of Sender or List-Id,
148 o Practice: a statement according to the [RFC2822].From domain
149 holder of externally verifiable behavior in the email messages it
152 o Expectation: an expectation combines with a practice to convey
153 what the domain holder considers the likely survivability of the
154 practice for a receiver, in particular receivers that may be more
155 than one SMTP hop away.
157 o DKIM Signing Complete: a practice where the domain holder asserts
158 that all legitimate mail will be sent with a valid first party
161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
163 document are to be interpreted as described in RFC 2119 [RFC2119].
170Thomas Informational [Page 3]
172RFC 5016 DKIM-SSP-REQ October 2007
1753. SSP Problem Scenarios
177 The email world is a diverse place with many deployment
178 considerations. This section outlines expected usage scenarios where
179 DKIM signing/verifying will take place, and how a new protocol might
180 help to clarify the relevance of DKIM-signed mail.
1823.1. Problem Scenario 1: Is All Mail Signed with DKIM?
184 After auditing their outgoing mail and deploying DKIM signing for all
185 of their legitimate outgoing mail, a domain could be said to be DKIM
186 signing complete. That is, the domain has, to the best of its
187 ability, ensured that all legitimate mail purporting to have come
188 from that domain contains a valid DKIM signature.
190 A receiver in the general case doesn't know what the practices are
191 for a given domain. Thus, the receiver is at a disadvantage in not
192 knowing whether or not it should expect all mail to be signed from a
193 given domain. This knowledge gap leads to a trivially exploitable
194 bid-down attack where the attacker merely sends unsigned mail; since
195 the receiver doesn't know the practices of the signing domain, it
196 cannot treat the message any more harshly for lack of a valid
199 An information service that allows a receiver to query for the
200 practices and expectations of the first party domain when no valid
201 first party signature is found could be useful in closing this gap.
202 A receiver could use this information to treat such questionable mail
203 with varying degrees of prejudice.
205 Note that, for the foreseeable future, unrestricted use patterns of
206 mail (e.g., where users may be members of mailing lists, etc.) will
207 likely suffer occasional, non-malicious signature failure in transit.
208 While probably not a large percentage of total traffic, this kind of
209 breakage may be a significant concern for those usage patterns. This
210 scenario defines where the sender cannot set any expectation as to
211 whether an individual message will arrive intact.
213 Even without that expectation, a receiver may be able to take
214 advantage of the knowledge that the domain's practice is to sign all
215 mail and bias its filters against unsigned or damaged in transit
216 mail. This information should not be expected to be used in a binary
217 yes/no fashion, but instead as a data point among others in a
226Thomas Informational [Page 4]
228RFC 5016 DKIM-SSP-REQ October 2007
231 The following exchange illustrates problem scenario 1.
233 1. Mail with a [RFC2822].From domain Alice is sent to domain Bob
234 with a missing or broken DKIM first party signature from Alice.
236 2. Domain Bob would like to know whether that is an expected state
239 3. Domain Alice provides information that it signs all outgoing
240 mail, but places no expectation on whether it will arrive with an
241 intact first party signature.
243 4. Domain Bob could use this information to bias its filters to
244 examine the message with some suspicion.
2463.2. Problem Scenario 2: Illegitimate Domain Name Use
248 A class of mail typified by transactional mail from high-value
249 domains is currently the target of phishing attacks. In particular,
250 many phishing scams forge the [RFC2822].From address in addition to
251 spoofing much of the content to trick unsuspecting users into
252 revealing sensitive information. Domain holders sending this mail
253 would like the ability to give an enhanced guarantee that mail sent
254 with their domain name should always arrive with the proof that the
255 domain holder consented to its transmission. That is, the message
256 should contain a valid first party signature as defined above.
258 From a receiver's standpoint, knowing that a domain not only signs
259 all of its mail, but places a very high value on the receipt of a
260 valid first party signature from that domain is helpful. Hence, a
261 receiver knows that the sending domain signs all its mail, and that
262 the sending domain considers mail from this domain particularly
263 sensitive in some sense, and is asking the receiver to be more
264 suspicious than it otherwise might be of a broken or missing first-
265 party signature. A receiver with the knowledge of the sender's
266 expectations in hand might choose to process messages not conforming
267 to the published practices in a special manner. Note that the
268 ability to state an enhanced guarantee of a valid signature means
269 that senders should expect mail that traverses modifying
270 intermediaries (e.g., mailing lists, etc.) will likely be quarantined
271 or deleted; thus, this scenario is more narrow than problem scenario
274 Informative Note: a receiving filter may choose to treat scenario
275 2 much more harshly than scenario 1; where scenario 1 looks odd,
276 scenario 2 looks like something is very wrong.
282Thomas Informational [Page 5]
284RFC 5016 DKIM-SSP-REQ October 2007
287 1. Mail with a [RFC2822].From domain Alice is sent to domain Bob
288 with a missing or broken first party DKIM signature from domain
291 2. Domain Bob would like to know whether that is an expected state
294 3. Domain Alice provides information that it signs all outgoing
295 mail, and furthermore places an expectation that it should arrive
296 with an intact first party signature, and that the receiver
297 should be much more wary if it does not.
299 4. Domain Bob could use this information to bias its filters such
300 that it examines the message with great suspicion.
3024. SSP Deployment Considerations
304 Given the problems enumerated above for which we'd like SSP to
305 provide information to recipients, there are a number of scenarios
306 that are not related to the problems that are to be solved, per se,
307 but the actual mechanics of implementing/deploying the information
308 service that SSP would provide.
3104.1. Deployment Consideration 1: Outsourced Signing
312 Many domains do not run their own mail infrastructure, or may
313 outsource parts of it to third parties. It is desirable for a domain
314 holder to have the ability to delegate to other entities the ability
315 to sign for the domain holder. One obvious use scenario is a domain
316 holder from a small domain that needs to have the ability for their
317 outgoing ISP to sign all of their mail on behalf of the domain
318 holder. Other use scenarios include outsourced bulk mail for
319 marketing campaigns, as well as outsourcing various business
320 functions, such as insurance benefits, etc.
3224.2. Deployment Consideration 2: Subdomain Coverage
324 An SSP client will perform lookups on incoming mail streams to
325 provide the information as proposed in the problem scenarios. The
326 domain part of the first address of the [RFC2822].From will form the
327 basis to fetch the published information. A trivial attack to
328 circumvent finding the published information can be mounted by simply
329 using a subdomain of the parent domain that doesn't have published
330 information. This attack is called the subdomain attack: that is, a
331 domain wants to not only publish a policy for a given DNS label it
332 controls, but it would also like to protect all subdomains of that
333 label as well. If this characteristic is not met, an attacker would
334 need only create a possibly fictitious subdomain that was not covered
338Thomas Informational [Page 6]
340RFC 5016 DKIM-SSP-REQ October 2007
343 by the SSP's information service. Thus, it would be advantageous for
344 SSP to not only cover a given domain, but all subdomains of that
3474.3. Deployment Consideration 3: Resent Original Mail
349 Resent mail is a common occurrence in many scenarios in the email
350 world of today. For example, domain Alice sends a DKIM-signed
351 message with a published practice of signing all messages to domain
352 Bob's mailing list. Bob, being a good net citizen, wants to be able
353 to take his part of the responsibility of the message in question, so
354 he DKIM signs the message, perhaps corresponding to the Sender
357 Note that this scenario is completely orthogonal to whether Alice's
358 signature survived Bob's mailing list: Bob merely wants to assert his
359 part in the chain of accountability for the benefit of the ultimate
360 receivers. It would be useful for this practice to be encouraged as
361 it gives a more accurate view of who handled the message. It also
362 has the side benefit that remailers that break DKIM first party
363 signatures can be potentially assessed by the receiver based on the
364 receiver's opinion of the signing domains that actually survived.
3664.4. Deployment Consideration 4: Incremental Deployment of Signing
368 As a practical matter, it may be difficult for a domain to roll out
369 DKIM signing such that they can publish the DKIM Signing Complete
370 practice given the complexities of the user population, the
371 outsourced vendors sending on its behalf, etc. This leaves open an
372 exploit that high-value mail, such as in Problem Scenario 2, must be
373 classified to the least common denominator of the published
374 practices. It would be desirable to allow a domain holder to publish
375 a list of exceptions that would have a more restrictive practices
376 statement. NB: this consideration has been deemed met by the
377 mechanisms provided by the base DKIM signing mechanism; it is merely
378 documented here as having been an issue.
380 For example, bigbank.example.com might be ready to say that
381 statements@bigbank.example.com is always signed, but the rest of the
382 domain, say, is not. Another situation is that the practices of some
383 address local parts in a given domain are not the same as practices
384 of other local parts. Using the same example of
385 statements@bigbank.example.com being a transactional kind of email
386 that would like to publish very strong practices, mixed in with the
387 rest of the user population local parts, which may go through mailing
388 lists, etc., for which a less strong statement is appropriate.
394Thomas Informational [Page 7]
396RFC 5016 DKIM-SSP-REQ October 2007
399 It should be said that DKIM, through the use of subdomains, can
400 already support this kind of differentiation. That is, in order to
401 publish a strong practice, one only has to segregate those cases into
402 different subdomains. For example: accounts.bigbank.example.com
403 would publish constrained practices, while
404 corporateusers.bigbank.example.com might publish more permissive
4074.5. Deployment Consideration 5: Performance and Caching
409 Email service provides an any-any mesh of potential connections: all
410 that is required is the publication of an MX record and an SMTP
411 listener to receive mail. Thus, the use of SSP is likely to fall
412 into two main scenarios, the first of which are large, well-known
413 domains that are in constant contact with one another. In this case,
414 caching of records is essential for performance, including the
415 caching of the non-existence of records (i.e., negative caching).
417 The second main scenario is when a domain exchanges mail with a much
418 smaller volume domain. This scenario can be both perfectly normal as
419 with the case of vanity domains, and unfortunately, a vector for
420 those sending mail for anti-social reasons. In this case, we'd like
421 the message exchange burden to SSP querier to be low, since many of
422 the lookups will not provide a useful answer. Likewise, it would be
423 advantageous to have upstream caching here as well so that, say, a
424 mailing list exploder on a small domain does not result in an
425 explosion of queries back at the root and authoritative server for
4284.6. Deployment Consideration 6: Human Legibility of Practices
430 While SSP records are likely to be primarily consumed by an
431 automaton, for the foreseeable future they are also likely to be
432 inspected by hand. It would be nice to have the practices stated in
433 a fashion that is also intuitive to the human inspectors.
4354.7. Deployment Consideration 7: Extensibility
437 While this document pertains only to requirements surrounding DKIM
438 signing practices, it would be beneficial for the protocol to be able
439 to extend to other protocols.
4414.8. Deployment Consideration 8: Security
443 SSP must be able to withstand life in a hostile, open-Internet
444 environment. These include DoS attacks, and especially DoS attacks
445 that leverage themselves through amplification inherent in the
446 protocol. In addition, while a useful protocol may be built without
450Thomas Informational [Page 8]
452RFC 5016 DKIM-SSP-REQ October 2007
455 strong source authentication provided by the information service, a
456 path to strong source authentication should be provided by the
457 protocol, or underlying protocols.
461 This section defines the requirements for SSP. As with most
462 requirements documents, these requirements define the MINIMUM
463 requirements that a candidate protocol must provide. It should also
464 be noted that SSP must fulfill all of the requirements.
4665.1. Discovery Requirements
468 Receivers need a means of obtaining information about a sender's DKIM
469 practices. This requires a means of discovering where the
470 information is and what it contains.
472 1. The author is the first-party sender of a message, as specified
473 in the [RFC2822].From field. SSP's information is associated
474 with the author's domain name, and is published subordinate to
477 2. In order to limit the cost of its use, any query service
478 supplying SSP's information MUST provide a definitive response
479 within a small, deterministic number of message exchanges under
480 normal operational conditions.
482 Informative Note: this, for all intents and purposes is a
483 prohibition on anything that might produce loops or result in
484 extended delays and overhead; also though "deterministic"
485 doesn't specify how many exchanges, the expectation is "few".
487 Refs: Deployment Considerations, Sections 4.2 and 4.5.
489 3. SSP's publishing mechanism MUST be defined such that it does not
490 lead to multiple resource records of the same type for different
491 protocols residing at the same location.
493 Informative note: an example is multiple resource record of the
494 same type within a common DNS leaf. Hence, uniquely defined
495 leaf names or uniquely defined resource record types will
496 ensure unambiguous referencing.
498 Refs: Deployment Consideration, Section 4.2.
506Thomas Informational [Page 9]
508RFC 5016 DKIM-SSP-REQ October 2007
511 4. SSP retrieval SHOULD provide coverage for not only a given domain
512 but all of its subdomains as well. It is recognized that there
513 is some reasonable doubt about the feasibility of a widely
514 accepted solution to this requirement. If the working group does
515 not achieve rough consensus on a solution, it MUST document the
516 relevant security considerations in the protocol specification.
518 Refs: Deployment Considerations, Sections 4.2 and 4.5.
5205.2. SSP Transport Requirements
522 The publication and query mechanism will operate as an internet-based
523 message exchange. There are multiple requirements for this lower-
526 1. The exchange SHOULD have existing widespread deployment of the
527 transport layer, especially if riding on top of a true transport
528 layer (e.g., TCP, UDP).
530 Refs: Deployment Considerations, Sections 4.5 and 4.7.
532 2. The query/response in terms of latency time and the number of
533 messages involved MUST be low (less than three message exchanges
534 not counting retransmissions or other exceptional conditions).
536 Refs: Deployment Consideration, Section 4.5.
538 3. If the infrastructure doesn't provide caching (a la DNS), the
539 records retrieved MUST provide initiators the ability to maintain
540 their own cache. The existing caching infrastructure is,
541 however, highly desirable.
543 Refs: Deployment Consideration, Section 4.5.
545 4. Multiple geographically and topologically diverse servers MUST be
546 supported for high availability.
548 Refs: Deployment Considerations, Sections 4.5 and 4.7.
5505.3. Practice and Expectation Requirements
552 As stated in the definitions section, a practice is a statement
553 according to the [RFC2822].From domain holder of externally
554 verifiable behavior in the email messages it sends. As an example, a
555 practice might be defined such that all email messages will contain a
556 DKIM signature corresponding to the [RFC2822].From address. Since
557 there is a possibility of alteration between what a sender sends and
558 a receiver examines, an expectation combines with a practice to
562Thomas Informational [Page 10]
564RFC 5016 DKIM-SSP-REQ October 2007
567 convey what the [RFC2822].From domain considers the likely outcome of
568 the survivability of the practice at a receiver. For example, a
569 practice that a valid DKIM for the [RFC2822].From address is present
570 when it is sent from the domain, and an expectation that it will
571 remain present and valid for all receivers whether topologically
574 1. SSP MUST be able to make practices and expectation assertions
575 about the domain part of a [RFC2822].From address in the context
576 of DKIM. SSP will not make assertions about other addresses for
579 Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
581 2. SSP MUST provide a concise linkage between the [RFC2822].From and
582 the identity in the DKIM i= tag, or its default if it is missing
583 in the signature. That is, SSP MUST precisely define the
584 semantics of what qualifies as a first party signature.
586 Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
588 3. SSP MUST be able to publish a practice that the domain's signing
589 behavior is "DKIM Signing Complete". That is, all messages were
590 transmitted with a valid first party signature.
592 Refs: Problem Scenario 1, Section 3.1.
594 4. SSP MUST be able to publish an expectation that a verifiable
595 first party DKIM signature should be expected on receipt of a
598 Refs: Problem Scenario 2, Section 3.2.
600 5. Practices and expectations MUST be presented in SSP syntax using
601 as intuitive a descriptor as possible. For example, p=? would be
602 better represented as p=unknown.
604 Refs: Deployment Consideration, Section 4.6.
606 6. Because DKIM uses DNS to store selectors, there is always the
607 ability for a domain holder to delegate all or parts of the
608 _domainkey subdomain to an affiliated party of the domain
609 holder's choosing. That is, the domain holder may set an NS
610 record for _domainkey.example.com to delegate to an email
611 provider who manages the entire namespace. There is also the
612 ability for the domain holder to partition its namespace into
613 subdomains to further constrain third parties. For example, a
614 domain holder could delegate only _domainkey.benefits.example.com
618Thomas Informational [Page 11]
620RFC 5016 DKIM-SSP-REQ October 2007
623 to a third party to constrain the third party to only be able to
624 produce valid signatures in the benefits.example.com subdomain.
625 Last, a domain holder can even use CNAME's to delegate individual
626 leaf nodes. Given the above considerations, SSP need not invent
627 a different means of allowing affiliated parties to sign on a
628 domain's behalf at this time.
630 Refs: Deployment Consideration, Section 4.4.
632 7. Practices and expectations MUST be presented as an information
633 service from the signing domain to be consumed as an added factor
634 to the receiver's local policy. In particular, a practice or
635 expectation MUST NOT mandate any disposition stance on the
638 Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
640 8. There is no requirement that SSP publish practices of any/all
641 third parties that MUST NOT sign on the domain holder's behalf.
642 This should be considered out of scope.
644 INFORMATIVE NOTE: this is essentially saying that the protocol
645 doesn't have to concern itself with being a blacklist
648 Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
650 9. SSP MUST NOT be required to be invoked if a valid first party
653 Refs: Deployment Consideration, Section 4.2.
655 10. SSP MUST NOT provide a mechanism that impugns the existence of
656 non-first party signatures in a message. A corollary of this
657 requirement is that the protocol MUST NOT link practices of first
658 party signers with the practices of third party signers.
660 INFORMATIVE NOTE: the main thrust of this requirement is that
661 practices should only be published for that which the publisher
662 has control, and should not meddle in what is ultimately the
663 local policy of the receiver.
665 Refs: Deployment Consideration, Section 4.3.
674Thomas Informational [Page 12]
676RFC 5016 DKIM-SSP-REQ October 2007
6795.4. Extensibility and Forward Compatibility Requirements
681 1. SSP MUST NOT extend to any protocol other than DKIM for email at
682 this time. SSP SHOULD be extensible for protocols other than
685 Refs: Deployment Consideration, Section 4.7.
687 2. SSP MUST be able to add new practices and expectations within the
688 existing discovery/transport/practices in a backward compatible
691 Refs: Deployment Consideration, Section 4.7.
6936. Requirements for SSP Security
695 1. SSP for a high-value domain is potentially a high-value DoS
696 target, especially since the unavailability of SSP's record could
697 make unsigned messages less suspicious.
699 2. SSP MUST NOT make highly leveraged amplification or make-work
700 attacks possible. In particular, the work and message exchanges
701 involved MUST be order of a constant.
703 Refs: Deployment Consideration, Section 4.8.
705 3. SSP MUST have the ability for a domain holder to provide SSP's
706 data such that a receiver can determine that it is authentically
707 from the domain holder with a large degree of certainty. SSP may
708 provide means that provide less certainty in trade off for ease
711 Refs: Deployment Consideration, Section 4.8.
7137. Security Considerations
715 This document defines requirements for a new protocol and the
716 security related requirements are defined above. Since it is
717 expected that the new protocol will use the DNS as a basis for the
718 published SSP information, most if not all of the threats described
719 in [RFC4686] will be applicable.
723 Dave Crocker and Jim Fenton provided substantial review of this
724 document. Thanks also to Vijay Gurbani and David Harrington for
725 their helpful last call reviews.
730Thomas Informational [Page 13]
732RFC 5016 DKIM-SSP-REQ October 2007
7379.1. Normative References
739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
740 Requirement Levels", BCP 14, RFC 2119, March 1997.
742 [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
745 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
746 Identified Mail (DKIM)", RFC 4686, September 2006.
748 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
749 J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
750 Signatures", RFC 4871, May 2007.
757 San Francisco, California 94114
760 Phone: +1-408-525-5386
786Thomas Informational [Page 14]
788RFC 5016 DKIM-SSP-REQ October 2007
791Full Copyright Statement
793 Copyright (C) The IETF Trust (2007).
795 This document is subject to the rights, licenses and restrictions
796 contained in BCP 78, and except as set forth therein, the authors
797 retain all their rights.
799 This document and the information contained herein are provided on an
800 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
801 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
802 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
803 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
804 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
805 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
809 The IETF takes no position regarding the validity or scope of any
810 Intellectual Property Rights or other rights that might be claimed to
811 pertain to the implementation or use of the technology described in
812 this document or the extent to which any license under such rights
813 might or might not be available; nor does it represent that it has
814 made any independent effort to identify any such rights. Information
815 on the procedures with respect to rights in RFC documents can be
816 found in BCP 78 and BCP 79.
818 Copies of IPR disclosures made to the IETF Secretariat and any
819 assurances of licenses to be made available, or the result of an
820 attempt made to obtain a general license or permission for the use of
821 such proprietary rights by implementers or users of this
822 specification can be obtained from the IETF on-line IPR repository at
823 http://www.ietf.org/ipr.
825 The IETF invites any interested party to bring to its attention any
826 copyrights, patents or patent applications, or other proprietary
827 rights that may cover technology that may be required to implement
828 this standard. Please address the information to the IETF at
842Thomas Informational [Page 15]