idnits 2.17.1 draft-hamilton-content-md5-origin-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC1864, updated by this document, for RFC5378 checks: 1995-10-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9537 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 135, but no explicit reference was found in the text Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Martin Hamilton 3 INTERNET-DRAFT Loughborough University 4 Updates: RFC 1864 March 1998 6 The Content-MD5-Origin: header 8 draft-hamilton-content-md5-origin-00.txt 10 Status of This Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts 20 as reference material or to cite them other than as ``work in 21 progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 25 Shadow Directories on ds.internic.net (US East Coast), 26 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 27 munnari.oz.au (Pacific Rim). 29 Distribution of this memo is unlimited. Comments should be sent 30 directly to the author. 32 This Internet Draft expires September 1998. 34 Abstract 36 The Content-MD5: header specified in RFC 1864 has not been widely 37 deployed, though this would be highly desirable for a number of 38 reasons. The author conjectures that this lack of usage is due at 39 least in part to the requirement that only originating user agents 40 may add a Content-MD5: header. This proposal updates RFC 1864 to 41 remove that requirement, and defines the header Content-MD5-Origin: 42 for use by relaying hosts to indicate the point at which a Content- 43 MD5: header was added. 45 1. Extending the scope of the Content-MD5: header 47 RFC 1864 specifies that :- 49 The Content-MD5 field is generated by only an originating 50 user agent. Message relays and gateways are expressly forbidden 51 from generating a Content-MD5 field. 53 Whilst understandable, this restriction means that the technology 54 must be pushed out to very large numbers of end users before it can 55 be useful for the Internet community as a whole. 57 In order to maximize the deployment of the Content-MD5: header, it is 58 essential that intermediate (relaying) systems be allowed to generate 59 a Content-MD5: header, and that Content-MD5: headers may be generated 60 for arbitrary message objects (rather than just leaf nodes of MIME 61 objects). 63 The rationale for extending the RFC 1864 definition of Content-MD5: 64 is that in addition to the basic message integrity check function, it 65 provides a very effective means of protection for messaging systems 66 against a number of common problems, such as 68 * loops - e.g. malfunctioning "vacation" programs or failure 69 messages sent to mailing lists by broken server software 71 * multiple submissions - where the same message is injected 72 over and over again, e.g. due to broken user agent or 73 server software 75 * unsolicited bulk messaging - a special case of the above 77 It should be noted that Content-MD5: is not a complete solution in 78 itself. For example, in some loop situations it is not uncommon for 79 messages to include header information for diagnostic purposes. This 80 would likely render the Content-MD5: digest value useless, since it 81 would be different for each of the looping messages. 83 2. Introducing Content-MD5-Origin: 85 When a relaying host or system decides to create a Content-MD5: 86 header, it should also add a Content-MD5-Origin: header, with its 87 host name or Internet Protocol address as the right hand side. 89 For example :- 91 Content-MD5-Origin: plausible-deniability.lut.ac.uk 92 or 94 Content-MD5-Origin: [131.231.132.201] 96 Note that Internet Protocol addresses should be encapsulated within 97 square brackets, as in the second example above. 99 Where a relaying host has multiple domain names and/or IP addresses 100 (e.g. because it is multi-homed), any of these may be chosen 101 arbitrarily. Most messaging systems provide a way for the 102 administrator to indicate a host's "canonical" domain name or IP 103 address - this is usually a good choice for the value of the 104 Content-MD5-Orgin: header. 106 3. Security considerations 108 As noted in RFC 1864, Content-MD5: is no substitute for a strong 109 cryptographic message integrity check. In this context, however, 110 there is no authentication element to consider - the value of the 111 Content-MD5: header is simply being used as a "key", typically into a 112 hash database which may be used to eliminate duplicate/unwanted 113 messages. 115 Implementations should take care not to assume that the value of the 116 Content-MD5: header will always be 24 bytes or less - to avoid buffer 117 overrun problems. It would also be unwise to assume that the 118 characters in an arbitrary Content-MD5: header will be chosen from 119 the base64 character set mandated by RFC 1864. 121 Relaying/receiving hosts should take care to check that the value 122 supplied for the Content-MD5: header matches that calculated from a 123 fresh iteration of the algorithm on the message. Supplying a bogus 124 Content-MD5: header which was different every time would be an easy 125 way to subvert simple-minded implementations. A future document may 126 define a standard way for a relaying host to indicate that it has 127 received an invalid Content-MD5: header. 129 4. Acknowledgements 131 Thanks to Nathaniel Borenstein for comments and feedback. 133 5. References 135 [1] Myers, J. and Rose, M. "The Content-MD5 Header Field." RFC 136 1864, October 1995. 138 6. Author's address 140 Martin Hamilton 141 Department of Computer Studies 142 Loughborough University of Technology 143 Leics. LE11 3TU, UK 145 Email: m.t.hamilton@lut.ac.uk 147 This Internet Draft expires September 1998.