One document matched: draft-farrell-perpass-attack-06.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 RFC2026 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml">
<!ENTITY RFC2804 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2804.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.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">
<!ENTITY RFC6962 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6962.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-06.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 initials="H.T." surname="Tschofenig" fullname="Hannes Tschofenig ">
      <organization>ARM Ltd.</organization>
      <address>
        <postal>
          <street>110 Fulbourn Rd</street>
          <city>Cambridge</city>
          <code> CB1 9NJ </code>
          <country>Great Britain</country>
        </postal>
        <email>Hannes.tschofenig@gmx.net </email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>

<date year="2014" month="February"/>

<area>IETF</area>

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

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

<middle>

<!-- new intro suggested by Dave Crocker offlist and liked by various folk-->

<section title="Pervasive Monitoring is a Widespread Attack on Privacy">

<t>
   Pervasive Monitoring (PM) is widespread (and often covert)
   surveillance through intrusive gathering of protocol artefacts,
   including application content, 
or 
protocol meta-data such as headers.  Active or passive
   wiretaps and traffic analysis, 
(e.g., correlation, timing or measuring packet
   sizes), or subverting 
   the cryptographic keys used to secure protocols
   can also be used as part of pervasive monitoring.
PM is
   distinguished by being indiscriminate and very large-scale, rather
   than by introducing new types of technical compromise.
</t>

<t>
   The IETF community's technical assessment is that PM is an attack
   on the privacy of Internet users and organizations.  

   The IETF community has expressed strong agreement that PM is an
   attack that needs to be mitigated where possible, via the design of
   protocols that make PM significantly more
   expensive or infeasible.
   Pervasive Monitoring was discussed at the technical plenary of the
   November 2013 IETF meeting 
<xref target="IETF88Plenary"/> 
and then through extensive exchanges on
   IETF mailing lists.  This document records the IETF community's
   consensus and establishes the technical nature of PM.
</t>


<!-- old intro
<section title="Pervasive Monitoring is Indistinguishable from an Attack">

<t>The technical plenary of the November 2013 IETF meeting 
<xref target="IETF88Plenary"/> 
discussed
pervasive monitoring
(or surveillance) which 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, see
<xref target="RFC2026"/> Section 5)
formally documents that consensus.
</t>


<t>For the purposes of this document "pervasive monitoring" means often covert 
and very widespread
intrusive
gathering of protocol artefacts including application content,
protocol meta-data such as headers, or cryptographic keys used to secure protocols.  Active
or passive wiretaps, 
traffic analysis, correlation, timing or measuring packet sizes can
also be used as part of 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. The term is used here to refer to behavior that subverts
the intent of communicating parties without the agreement of those parties. An attack may change the content of the communication, record the
content or external characteristics of the communication, or through correlation with other communication
events, reveal information the parties 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.  We also use the term in the singular here, even though PM in
reality may consist of a multi-faceted set of coordinated attacks.  

</t>

<!-- -05 version
<t> 
In particular, the term attack, used technically, implies nothing
about the motivation of the actor mounting the attack.  
The motivation for
PM 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 actions by criminals.  The same
techniques can be used regardless of motivation. Thus we cannot defend against
the most nefarious actors while allowing monitoring by other actors no matter
how benevolent some might consider them to be, since
the actions required for the attack are indistinguishable from other attacks.
</t>
-->

<!-- Adrian's -->

<t>
In particular, the term attack, used technically, implies nothing
about the motivation of the actor mounting the attack.  
The
motivation for PM can range from non-targeted nation-state
surveillance, to legal but privacy-unfriendly purposes by commercial
enterprises, to illegal actions by criminals.  The same techniques 
to achieve PM can be used regardless of motivation.
Thus, we cannot defend against the most nefarious actors while
allowing monitoring by other actors no matter how benevolent some
might consider them to be, since the actions required are
indistinguishable from other attacks.  The motivation for PM is, 
therefore, not relevant for how PM is mitigated in IETF protocols. 
</t>

</section>

<section title="The IETF will work to Mitigate Pervasive Monitoring"> 

<t>"Mitigation" is a technical term that does not imply an ability to
completely prevent or thwart an attack.  Protocols that mitigate
PM will not prevent the attack, but can significantly
change the threat. 
(See the diagram on page 24 of RFC 4949 for how the
terms attack and threat are related.)
This can significantly increase the cost of attacking, force what was covert to
be overt, or make the attack more likely to be detected, possibly later.

</t>

<t>  IETF standards already provide mechanisms to protect Internet
communications and there are guidelines <xref target="RFC3552"/> for applying
these in protocol design. But those generally do not consider PM,
the confidentiality of protocol meta-data, countering traffic analysis nor data
minimisation. 
In all cases, there will remain some privacy-relevant information
that is inevitably disclosed by protocols.  
As technology advances,
techniques that were once only available to extremely well funded actors become
more widely accessible.  Mitigating PM is therefore a protection
against a wide range of similar attacks.
</t>

<t>
It is therefore timely to revisit the security and privacy properties of our
standards.  
The IETF will work to mitigate the
technical aspects of PM, just as we
do for protocol vulnerabilities in general.  
The ways in
which IETF protocols mitigate PM
will change over time as mitigation and attack techniques evolve and
so are not described here.  

</t>

<t>Those developing IETF specifications need to be able to describe how they
have considered PM, and, if the attack is relevant to the
work to be published, be able to justify related design decisions.  This does
not mean a new "pervasive monitoring considerations" section is needed in
IETF documentation. It means that, if asked, there needs to
be a good answer to the question "is pervasive monitoring relevant to this work
and if so how has it been considered?" </t>

<!-- 04 version
<t>
   In particular, architectural decisions, including which existing
   technology is re-used, may significantly impact the vulnerability of
   a protocol to PM.
   Those developing IETF specifications
   therefore need to consider mitigating PM when
   making these architectural decisions and be prepared to justify
   their decisions.  Getting adequate, early review of architectural
   decisions including whether appropriate mitigation of PM
   can be made is important.  Revisiting these architectural
   decisions late in the process is very costly.
</t>
-->

<t>
   In particular, architectural decisions, including which existing
   technology is re-used, may significantly impact the vulnerability of
   a protocol to PM.
   Those developing IETF specifications
   therefore need to consider mitigating PM when
   making these architectural decisions. 
   Getting adequate, early review of architectural
   decisions including whether appropriate mitigation of PM
   can be made is important.  Revisiting these architectural
   decisions late in the process is very costly.
</t>

<t>While PM is an attack, other forms of monitoring that
might fit the definition of PM can be
beneficial and not part of any attack, e.g. network management functions
monitor packets or flows and anti-spam mechanisms need to see mail message content. 
Some monitoring can even be part of the mitigation for PM,
for example Certificate Transparency <xref target="RFC6962"/> 
involves monitoring Public Key Infrastructure in ways that
could detect some PM attack techniques.
There is though a clear
potential for monitoring mechanisms to be abused for PM, so
this tension needs careful consideration in protocol design.  Making networks
unmanageable to mitigate PM is not an acceptable outcome,
but ignoring PM would go against the consensus documented 
here.  An appropriate balance will emerge over time as real
instances of this tension are considered.  </t>

<t>
Finally, the IETF, as a standards development organisation, does not control
the implementation or deployment of our specifications (though IETF
participants do develop many implementations), nor does the IETF standardise all
layers of the protocol stack. Moreover, the non-technical (e.g. legal and political)
aspects of mitigating pervasive monitoring are outside of the scope of the
IETF.  The broader Internet community will need to step forward to tackle PM,
if it is to be fully addressed.

</t>

<!-- maybe add this after an offlist chat with Dave Crocker -->
<t>
To summarise: current capabilities permit some actors to monitor content and
meta-data across the Internet at a scale never before seen.  This
pervasive monitoring is an attack on Internet privacy.  The IETF will
strive to produce specifications that mitigate pervasive monitoring
attacks.

</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 
   Internet Engineering Steering Group (IESG) and 
   the Internet Architecture Board (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 after discussions in both the IESG and IAB, but
   is published as an IETF-stream consensus document, in
   order to ensure that it properly reflects the consensus of
   the IETF community as a whole.
</t>
<!--
<t>[[Note (to be removed before publication): This draft is written as if IETF
consensus has been established for the text.]]</t>
-->


</section>

<section title="Security Considerations">

<t>This document 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
or comments:
Jari Arkko, 
Fred Baker,
Marc Blanchet,
Tim Bray,
Scott Brim,
Randy Bush,
Brian Carpenter,
Benoit Claise,
Alissa Cooper,
Dave Crocker,
Spencer Dawkins,
Avri Doria,
Wesley Eddy,
Adrian Farrel,
Joseph Lorenzo Hall,
Ted Hardie,
Sam Hartmann,
Paul Hoffman,
Bjoern Hoehrmann,
Phillip Hallam-Baker,
Russ Housley,
Joel Jaeggli,
Stephen Kent,
Eliot Lear,
Barry Leiba,
Ted Lemon,
Subramanian Moonesamy,
Erik Nordmark,
Pete Resnick,
Peter Saint-Andre,
Andrew Sullivan,
Sean Turner,
Nicholas Weaver,
Stefan Winter,
and
Lloyd Wood.

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;
<!--
&RFC2026;
-->
&RFC2804;
&RFC3552;
&RFC4844;
&RFC4949;
&RFC5741;
&RFC6973; 
&RFC6962; 

     <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>