One document matched: draft-ietf-marf-redaction-01.xml

<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfcXXXX.dtd'>
<rfc ipr="trust200902" docName="draft-ietf-marf-redaction-01" category="info">
	<?rfc toc="yes" ?>
	<?rfc tocompact="yes" ?>
	<?rfc symrefs="yes" ?>
	<?rfc sortrefs="yes" ?>
	<?rfc compact="yes" ?>
	<?rfc rfcprocack="yes" ?>
	
	<front>
		<title abbrev="Redaction">
			Redaction of Potentially Sensitive Data from Mail Abuse Reports
		</title>
		<author initials="J.D." surname="Falk" fullname="J.D. Falk" role="editor">
			<organization>Return Path</organization>
			<address>
				<postal>
					<street>100 Mathilda Place, Suite 100</street>
					<city>Sunnyvale</city>
					<region>CA</region>
					<code>94086</code>
					<country>US</country>
				</postal>
				<email>ietf@cybernothing.org</email>
				<uri>http://www.returnpath.net/</uri>
			</address>
		</author>
		<date/>
		
		<area>Applications</area>
		<workgroup>MARF Working Group</workgroup>
		<keyword>ARF</keyword>
		<keyword>MARF</keyword>
		<keyword>feedback loop</keyword>
		<keyword>spam reporting</keyword>
		
		<abstract>
			<t> Email messages often contain information which might be considered
				private or sensitive, per either regulation or social norms.  When
				such a message becomes the subject of a report intended to be
				shared with other entities, the report generator may wish to
				redact or elide the sensitive portions of the message.  This memo
				suggests one method for doing so effectively. </t>
		</abstract>
	</front>
	
	<middle>
		<section title="Introduction">
			<t> <xref target="ARF"/> defines a message format for sending reports of 
				abuse in the messaging infrastructure, with an eye toward automating 
				both the generating and consumption of those reports. </t>
			
			<t> For privacy considerations it might be the policy of a report
			    generator to redact, or obscure, portions of the report that might
			    identify an end user that caused the report to be generated.
			    Precisely how this is done is unspecified in <xref target="ARF"/> 
				as it will generally be a matter of local policy.  That specification 
				does admonish generators against being too over-zealous with this
			    practice, as obscuring too much data makes the report non-actionable. </t>

			<t> Previous redaction practices, such as replacing local-parts of
			    addresses with a uniform string like "xxxxxxxx", often frustrates any
			    kind of prioritizing or grouping of reports. </t>

			<t> Generally, it is assumed that the recipient-identifying fields of a 
				message, when copied into a report, are to be obscured to protect 
				the identity of then end user who submitted the complaint about the 
				message.  However, it is also presumed that other data will be left 
				intact, and that data could theoretically be correlated against log
				files or other resources to determine the intended recipient of the 
				message. </t>
		</section>

		<section title="Recommended Practice">
			<t> To enable correlation of reports that might refer to a common but
			    anonymous source, the following redaction practice is recommended
			    (but not required): </t>
			
			<t>
				<list style="numbers">
					<t> Select an arbitrary string that will be used by an Administrative
						Domain (ADMD) that generates reports.  This string will not be 
						changed except according to a key rotation policy or similar.  
						Call this the "redaction key". </t>
					
					<t> Identify string(s) (such as local-parts of email addresses) in a
						message that need to be redacted.  Call this the "private data". </t>
						
					<t> Construct a new string that is a copy of the redaction key with
						the private data concatenated to it. </t>
						
					<t> Compute a digest of that string with any hashing/digest algorithm
						such as SHA1. </t>
						
					<t> Encode that hash with the base64 algorithm as defined in 
						<xref target="MIME"/>. </t>
						
					<t> Replace the private data with the encoded hash when generating
						the report. </t>
				</list>
			</t>
			
			<t> This has the effect of obscuring the data in an irreversible way but
			    still allows the report recipient to observe that numerous reports
			    are about one particular end user.  Such detection enables the
			    receiver to prioritize its reactions based on problems that appear to
			    be focused on specific end users that may be under attack. </t>
			
		</section>
		
		<section title="Security and Privacy Considerations">
			<t> Security issues with respect to these reports are found in 
				<xref target="ARF"/>. </t>
				
			<t> While the method of redaction described in this document may 
				somewhat reduce the likelihood of some types of private data from
				leaking between Administrative Domains, it is extremely unlikely
				that report generation software could ever be created to recognize
				all of the different ways that private information may be expressed
				through human written language.  If further protections are
				required, implementors may wish to consider establishing legal
				contracts or other non-technology-based agreements between the 
				relevant entities. </t>
		</section>
		
		<section title="Acknowledgements">
			<t> Much of the text in this document was initially moved from 
				<xref target="DKIM-REPORTING" />, by Murray Kucherawy and Hilda
				Fontana with contributions from Monica Chew, Tim Draegen, Michael
				Adkins, and myself. </t>
		</section>
		
		<section title="IANA Considerations">
			<t> This memo includes no request to IANA. </t>
		</section>
	</middle>
	
	<back>
		<references>

			<reference anchor='MIME'>
				<front>
					<title abbrev='Internet Message Bodies'>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
					<author initials='N.' surname='Freed' fullname='Ned Freed'>
						<organization>Innosoft International, Inc.</organization>
					</author>
					<author initials='N.S.' surname='Borenstein' fullname='Nathaniel S. Borenstein'>
						<organization>First Virtual Holdings</organization>
					</author>
					<date year='1996' month='November' />
				</front>
				<seriesInfo name='RFC' value='2045' />
			</reference>

			<reference anchor='ARF'>
				<front>
					<title>An Extensible Format for Email Feedback Reports</title>
					<author initials='Y.' surname='Shafranovich' fullname='Y. Shafranovich'>
						<organization />
					</author>
					<author initials='J.' surname='Levine' fullname='J. Levine'>
						<organization />
					</author>
					<author initials='M.' surname='Kucherawy' fullname='M. Kucherawy'>
						<organization />
					</author>
					<date year='2010' month='August' />
				</front>
				<seriesInfo name='RFC' value='5965' />
			</reference>
			
			<reference anchor="DKIM-REPORTING"
					target="http://tools.ietf.org/html/draft-ietf-marf-dkim-reporting">
				<front>
					<title>Authentication Failure Reporting using the Abuse Report
						Format</title>
					<author initials="M." surname="Kucherawy" fullname="Murray S. Kucherawy">
						<organization>Cloudmark</organization>
					</author>
					<author initials="H." surname="Fontana" fullname="Hilda Fontana">
						<organization>eCert Systems</organization>
					</author>
					<date month="January" year="2011" />
				</front>
				<seriesInfo name="I-D" value="draft-ietf-marf-dkim-reporting"/>
			</reference>
		</references>
	</back>
</rfc>