One document matched: draft-farrell-perpass-attack-02.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1984 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1984.xml">
<!ENTITY RFC2804 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2804.xml">
<!ENTITY RFC4844 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4844.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC5741 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5741.xml">
<!ENTITY RFC6973 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6973.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc strict="no" ?>
<?rfc toc="no"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="bcp" ipr="trust200902" docName="draft-farrell-perpass-attack-02.txt">
<front>
<title abbrev="Pervasive Monitoring is an Attack">Pervasive Monitoring is an Attack</title>

<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="Hannes Tschofenig" initials="H." 
surname="Tschofenig">
<organization></organization>
<address>
<postal>
<street></street>
<city>Brussels</city>
<region></region>
<code></code>
<country>Belgium</country>
</postal>
<phone></phone>
<email>hannes.tschofenig@gmx.net</email>
</address>
</author>

<date year="2013" month="December"/>

<area>IETF</area>

<workgroup>Network Working Group</workgroup>
<keyword>pervasive monitoring</keyword>

<abstract>
<t>
The IETF has consensus that pervasive monitoring is
a technical attack that should be mitigated in the design of IETF
protocols, where possible. 
</t>
</abstract>
</front>

<middle>

<section title="It's an Attack">

<t>[[Note (to be removed before publication): This draft is written as if IETF
consensus has been established for the text.]]</t>

<t>The technical plenary of IETF 88 <xref target="IETF88Plenary"/> discussed
pervasive monitoring. 
Such pervasive surveillance requires the monitoring party to take
actions that are indistinguishable from an attack on Internet communications.
Participants at that meeting therefore expressed strong agreement that this was an
attack that should be mitigated where possible via the design of
protocols that make pervasive monitoring significantly more expensive or
infeasible.  
This Best Current Practice (BCP) formally documents that consensus,
having been through an IETF last call.  </t>

<t>For the purposes of this BCP "pervasive monitoring" means very widespread
privacy-invasive gathering of protocol artefacts including application content,
protocol meta-data (such as headers) or keys used to secure protocols.  Other
forms of traffic analysis, for example, correlation, timing or measuring packet sizes can
also be used for pervasive monitoring.  
</t>
<!--
A fuller problem statement with more
examples and description can be found in <xref target="ProblemStatement"/>.
-->

<t>The term "attack" is used here in a technical sense that differs
somewhat from common English usage. 
In common English usage, an "attack" is an aggressive action
perpetrated by an opponent, intended to enforce the opponent's will on the
attacked party. In the Internet, the term is used to refer to a behavior that
subverts the intent of a communicator without the agreement of the parties to
the communication. It may change the content of
the communication, record the content of the communication, or through
correlation with other communication events or attempts, reveal information the
communicator did not intend to be revealed. 
It
may also have other effects that similarly subvert the intent of a
communicator.
<xref target="RFC4949"/> contains a more complete definition for the term
"attack" as used here.  We also use the term in the singular here, even though
pervasive monitoring in reality may require a multi-faceted set of coordinated
attacks.  

</t>

<t> In particular, the term "attack", when used technically, implies nothing
about the motivation of the actor mounting the attack.  
   The motivation behind pervasive monitoring is not relevant for this
   document,
but can range from non-targeted nation-state surveillance, to
legal but privacy-unfriendly purposes by commercial
enterprises, to illegal purposes by criminals. 
The same techniques can be used regardless of motivation
   and we cannot defend against the most nefarious actors while allowing
   monitoring by other actors no matter how benevolent some might
   consider them to be.  

As technology advances, techniques that were
   once only available to extremely well funded actors become more 
   widely accessible.  

Mitigating this attack is therefore a protection
   against wider usage of pervasive monitoring.
</t>

</section>

<section title="And We Will Continue to Mitigate the Attack"> 

<t>The IETF also has consensus to, where possible, work to mitigate the
technical parts of the pervasive monitoring attack, in just the same way as we
continually do for these and any other protocol vulnerability.  </t>

<t>There are various ways in which IETF protocols can be designed in order to
mitigate pervasive monitoring, but those will change over time as mitigation
and attack techniques develop and so are not described here. This BCP simply
records the consensus to design protocols so as to mitigate the attack, where
possible.</t>

<t> 
More limited-scope monitoring to assist with network management
that is required in order to operate the network or an application is not
considered pervasive monitoring. There is though a clear potential for such
limited monitoring
mechanisms to be abused as part of pervasive monitoring, so this
tension needs careful consideration in protocol design. Making networks
unmanageable in order to mitigate pervasive monitoring would not be an
acceptable outcome. But equally, ignoring pervasive monitoring in designing
network management mechanisms would go against the consensus documented in this
BCP.  An appropriate balance will likely emerge over time as real instances of
this tension are considered. 
</t>

<t>It is also important to note that the term "mitigation" is a technical term
that does not necessarily imply an ability to completely prevent or thwart an
attack.  As in common English usage, this term is used here in the
sense of "make less severe, serious, or painful." <xref target="OED"/> In this
case, designing IETF protocols to mitigate pervasive monitoring will almost
certainly not completely prevent such from happening, 
but can significantly increase the cost of such monitoring
or force what was covert monitoring to be more overt or more
likely to be detected (possibly later) via other means.  And even where the
IETF has done this work well and that has been fully deployed, there will still
be some privacy-relevant information that will inevitably be disclosed by
protocols.  </t>

<t>
While RFC 4949 does not contain a definition for the term
mitigation, we prefer it here to the term countermeasure
which is defined in RFC 4949 since the
latter term is more often understood to mean putting
in place a more fully
effective mitigation of an attack.
</t>


<t>Finally, we note that the IETF is not equipped to tackle the non-technical
aspects of mitigating pervasive surveillance.  Others need to
step forward to tackle those if pervasive monitoring is to be fully
addressed.</t>


</section>

<section title="Process Note">
<t>
   In the past, architectural statements of this sort, e.g.,
   <xref target="RFC1984"/> and
   <xref target="RFC2804"/> have been published as joint products of the IESG and IAB.
   However, since those documents were published, the IETF and IAB have
   separated their publication "streams" as described in 
   <xref target="RFC4844"/> and
   <xref target="RFC5741"/>. This document was initiated by both the IESG and IAB, but
   it is published as an IETF-stream consensus document, having
   garnered the consensus of the IETF as approved by the IESG. 
</t>

</section>

<section title="Security Considerations">

<t>This BCP is entirely about privacy. More information about the relationship
between security and privacy threats can be found in <xref target="RFC6973"/>.
Section 5.1.1 of <xref target="RFC6973"/> specifically addresses surveillance
as a combined security-privacy threat. </t>

</section>

<section title="IANA Considerations">

<t>There are none. We hope the RFC editor
deletes this section before publication.</t>


</section>

<section title="Acknowledgements">

<t> We would like to thank the participants of the IETF 88 technical plenary
for their feedback. 

Thanks in particular to the following for useful suggestions
that resulted in changes to this text:
Jari Arkko, 
Fred Baker,
Marc Blanchet,
Brian Carpenter,
Benoit Claise,
Spencer Dawkins,
Adrian Farrel,
Russ Housley,
Joel Jaeggli,
Eliot Lear,
Barry Leiba,
Ted Lemon,
Erik Nordmark,
Pete Resnick,
Peter Saint-Andre,
and
Sean Turner.

Additionally, we would like to thank all those who
contributed suggestions on how to improve Internet security 
and privacy or
who commented on this on various
IETF mailing lists, such as the ietf@ietf.org and the perpass@ietf.org lists.
</t>

</section>

</middle>

<back>


<references title="Informative References">
&RFC1984;
&RFC2804;
&RFC4844;
&RFC4949;
&RFC5741;
&RFC6973; 

     <reference anchor="IETF88Plenary">
        <front>
          <title>IETF 88 Plenary Meeting Materials</title>
           <author>
            <organization>IETF</organization>
          </author>
          <date month="Nov" year="2013"/>
        </front>
        <seriesInfo name=""
          value="URL: https://datatracker.ietf.org/meeting/88/materials.html" />
        
        <format target="https://datatracker.ietf.org/meeting/88/materials.html"
          type="HTML" />
      </reference>
      

<!--
 <reference anchor="ProblemStatement">
        <front>
          <title>Pervasive Monitoring: Problem Statement</title>
           <author>
            <organization>Richard Barnes</organization>
          </author>
          <date month="Nov" year="2013"/>
        </front>
        <seriesInfo name="OUP"/>
        
        <format target="https://www.ietf.org"
          type="HTML" />
      </reference>
-->
      
<reference anchor="OED">
	<front>
  		<title>Oxford Dictionary of English</title>
  		<author>
			<organization>Stevenson, Angus</organization>
		</author>
  		<date year="2010"/>
	</front>
  <seriesInfo name="Oxford University Press"
    value="http://www.oxforddictionaries.com/definition/english/mitigate"/>
</reference>

</references>



</back>
</rfc>