One document matched: draft-cooper-ietf-privacy-requirements-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="no" ?>
<?rfc linkmailto="yes" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1984 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1984.xml'>
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2804 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2804.xml'>
<!ENTITY RFC3365 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3365.xml'>
<!ENTITY RFC3552 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml'>
<!ENTITY RFC4322 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4322.xml'>
<!ENTITY RFC4941 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941.xml'>
<!ENTITY RFC6973 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6973.xml'>
]>

<rfc category="bcp" ipr="trust200902" docName="draft-cooper-ietf-privacy-requirements-01.txt">

<front>

<title abbrev="Privacy Requirements for IETF Protocols">Privacy Requirements for IETF Protocols</title>   
    
	<author initials="A." surname="Cooper" fullname="Alissa Cooper">
    <organization>CDT</organization>
    <address>
      <postal>
        <street>1634 Eye St. NW, Suite 1100</street>
        <city>Washington</city>
		  <region>DC</region>
        <code>20006</code>
        <country>US</country>
      </postal>
      <phone>+1-202-637-9800</phone>
      <email>acooper@cdt.org</email>
      <uri>http://www.cdt.org/</uri>
    </address>
  </author>

<author fullname="Stephen Farrell" initials="S." surname="Farrell">
<organization>Trinity College Dublin</organization>
<address>
<postal>
<street></street>
<city>Dublin</city>
<region></region>
<code>2</code>
<country>Ireland</country>
</postal>
<phone>+353-1-896-2354</phone>
<email>stephen.farrell@cs.tcd.ie</email>
</address>
</author>

<author fullname="Sean Turner" initials="S." surname="Turner">
<organization>IECA, Inc.</organization>
<address>
<postal>
<street>3057 Nutley Street, Suite 106 </street>
<city>Fairfax</city>
<region>VA</region>
<code>22031</code>
<country>USA</country>
</postal>
<phone>+1.703.628.3180 </phone>
<email>turners@ieca.com</email>
</address>
</author>


<date year="2013"/> 

<abstract>
    
<t>It is the consensus of the IETF that our protocols be designed to avoid
privacy violations to the extent possible. This document establishes
a number of protocol design choices as Best Current Practices for the purpose
of avoiding such violations.</t>

</abstract>

</front>

<middle>

<section anchor="introduction" title="Introduction">

<t>The IETF has long-standing principles that support strong security in
protocol design and a tradition of encouraging protocol designers to take these
principles into account. <xref target="RFC1984" /> articulated the view that
encryption is an important tool to protect the cofidentiality of
communications, and that as such it should be encouraged and available to all.
<xref target="RFC3365" /> requires that all protocols implement strong
security. <xref target="RFC3552" /> provides guidance about how to consider
security in protocol design and how to document security choices. In <xref
target="RFC2804" />, the IETF established a policy of not considering
wiretapping requirements in IETF standards-track protocols. 
<xref target="RFC6973" /> explains the many different aspects of
privacy that can be affected by Internet protocol design and provides guidance
to help designers consider privacy in their work.</t>

<t>This document extends the existing body of IETF principles concerning
security by articulating Best Current Practices for avoiding privacy
violations and establishing support for privacy as a principle of IETF protocol
design. These principles, old and new, should be applied when designing new protocols,
   and where applicable, should be considered for updates of existing
   protocols.</t> 
   
   <t>It is also the consensus of the IETF that pervasive surveillance is an attack on privacy that should be defended against through protocol design.</t> 

<t>Discussion of this draft is directed to the ietf-privacy@ietf.org list.</t>

</section>
	
<!-- ====================================================================== -->
<section title="Terminology">

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in <xref target="RFC2119"
/>.  These words take their normative meanings only when they are presented in
ALL UPPERCASE.</t>

<t>"Opportunistic encryption" is defined as encryption without any pre-arrangement
specific to the pair of systems involved (e.g., by using a Diffie-Hellman exchange). See <xref target="RFC4322" />.</t>

<t>Privacy-specific terminology is provided in <xref target="RFC6973" />. Of particular relevance to this document is the term "personal data," defined as "any information relating to an individual who can be identified, directly or indirectly." Identifiers such as IP addresses that can remain consistent over time or that particular parties associate with directly identifiable information (such as a real name or street address) are therefore considered to be personal data.</t>


</section>

<!-- ====================================================================== -->
<section anchor="core" title="Recommendations">

<t>
There are inherent privacy risks with protocols that allow the communicating
parties to store personal data, transport personal data, or are vulnerable to
other parties observing the personal data in the exchanged communications. Most
Internet communications involve such risks, which can allow entities to build large
databases of information that by themselves or in conjunction with other
databases can identify people and their actions in invasive ways.  
</t>

<t>Therefore, to the extent consistent with basic protocol operation and
management, standards-track IETF protocols that involve transmission of
personal data:</t>

<t><list style="numbers">

<t>MUST minimize their use of such personal data, and</t> 

<t>
where personal data is sent,
MUST have well-defined and interoperable ways to send such data encrypted
for the intended recipient(s).</t>

</list></t>

<t>

While existing principles call for strong security, it is important to note
that strong security only in cases where the other party can be authenticated
does not by itself solve all privacy problems. To guard against dangers of
large-scale privacy attacks, some protection is needed also for other
situations.  

</t>

<t>

As a consequence, at minimum, opportunistic encryption MUST be 
well-defined for new IETF standards track protocols. This requirement 
can be waived only in exceptional circumstances where the protocol's 
utility would be eliminated or severely diminished if opportunistic 
encryption were defined.   
Note that encryption provides one aspect of privacy protection, 
namely confidentiality.
In most cases
it will be better to (also) specify how to do one-sided (e.g., TLS server authentication as commonly used in the web) or 
mutually authenticated
encryption. 
Where both opportunistic and one-sided or mutually authenticated
encryption are specified, protocols MUST also protect against downgrade
attacks so that scenarios where authentication is required cannot
easily be manipulated into using opportunistic encryption which 
will often be subject to man-in-the-middle attacks. 
</t>

<t>Note that these encryption requirements are contingent on practicality - if
some personal data really has to be
sent in clear for a protocol to be able to operate, and
even opportunistic encryption is not possible, then a
standards-track protocol that does not define how to protect
that data will be consistent with this BCP. The IETF will
have to decide in such cases whether standardising that
protocol benefits the Internet or not.</t>

<t>
Many IETF protocols allow for some data items to be optionally
or conditionally sent. If personal data can be sent, then the
conditions above apply.
</t>

<t>Specifications that do not meet the criteria
above MUST include (or reference) an explanation of why they do not conform to this BCP.</t>

</section>

<section anchor="eg" title="Examples and Explanation">

<t>This section has some examples and explanatory material. [[More,
including references,  
will be added as discussion evolves.]]
</t>

<t>
DHCP is an example of a protocol where it seems quite hard to
provide useful confidentiality. Should a new DHCP option be
defined that carries personal data, then the IETF would have 
to decide if the benefit of that outweighs the potential
privacy cost.
</t>

<t>
For some protocols, layering on top of a security protocol
like TLS, SSH or IPsec can be a useful way to provide
confidentiality. However, just because it could be possible
to do that does not mean that that is sufficient to claim
conformance with this BCP. For example, claiming that
Diameter conformed to this BCP becuase one could in
principle run Diameter over IPsec would not be credible,
as it seems that such deployments are rare to non-existent.
In the same way that being being realistic is important when
we consider a claim that
sending personal data is unavoidable, it is just as
important when claiming that layering on top of a 
security protocol can meet the requirements of this
BCP.
</t>

<t>For some protocols, minimizing the use of personal data involves limiting the lifetime of identifiers. In cases where an identifier
   refers to an individual (or a proxy for an individual, such as a host
   device or software instance), the longer that identifier persists and
   the more contexts in which it is used, the more it can facilitate
   correlation and tracking of information related to the individual and
   his or her activities.  Creating identifiers that have limited lifetimes by default reduces the possibility that multiple protocol
   interactions or communications can be correlated back to the same
   individual. <xref target="RFC4941" /> provides an example in the case of stateless autoconfiguration of IPv6 interface identifiers.</t>

<t>

Since the goal here is to have a BCP that covers all IETF standards track
protocols we  clearly cannot address all aspects of privacy, for example user
participation, since that would only be relevant for a small proportion
of IETF protocols. 

</t>

<t>
One could consider mininimising the personal data sent by
IETF protocols as a form being conservative in what you
send, one of the longest standing principles in IETF
protocol design. There doesn't seem to be an equivalent
here for being liberal in what you accept.

</t>


</section>

	 <!-- ====================================================================== -->

    <section anchor="SecurityConsiderations" title="Security Considerations">

<t>This document articulates a set of Best Current Practices for privacy that
extend the IETF's existing security principles. At times, privacy and security may appear to be in tension. For example, adherence to the recommendation in this BCP to minimize the use of personal data will likely yield less use of persistent identifiers associated with individual users. Reducing the use of persistent identifiers can help attackers shield their identities and activities just as it can for legitimate users. However, even relatively unsophisticated attackers already have at their disposal a variety of tools for cloaking their identities. Recommending the minimization of personal data use at the protocol level can benefit the vast majority of legitimate users who depend on IETF protocols without materially improving attackers' existing tools for guarding their identities.</t>

<t>Similarly, malware and other attack traffic can generally already be transmitted using object encryption or protocol encryption if attackers so choose. Recommending that IETF protocols define mechanisms for opportunistic encryption can increase the availability of confidentiality protection to legitimate users without significantly changing the set of tools that attackers already use to shield their traffic from being identified and their attacks from being thwarted.</t>

</section>

    <!-- ====================================================================== -->

    <section anchor="iana" title="IANA Considerations">
	<t>
This document does not require actions by IANA. </t>
    </section>

    <!-- ====================================================================== -->

    <section title="Acknowledgements">
	<t>Thanks to the following for useful comments. These folks
	may or may not agree with the content.

	</t>
	<t>
 
	Jari Arkko,
	Bernard Aboba,
	Scott Brim,
	Benoit Claise,
	Nick Doty,
	Spencer Dawkins,
	Eliot Lear,
	Ted Lemon,
	SM,
	Avri Doria,
	Brian Trammell,
	Robin Wilton,
	</t>
    </section>

 <!-- ====================================================================== -->

</middle>
<back>	
	    <references title="Informative References">
		&RFC1984;
		&RFC2119;
		&RFC2804;
		&RFC3365;
		&RFC3552;
		&RFC4322;
		&RFC4941;
		&RFC6973;
	</references>
</back>
</rfc>