One document matched: draft-farrell-perpass-attack-03.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-03.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>
Pervasive monitoring is
a technical attack that should be mitigated in the design of IETF
protocols, where possible. 
</t>
</abstract>
</front>

<middle>

<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. Here, 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, 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."  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="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
pervasive monitoring 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 pervasive monitoring,
the confidentiality of protocol meta-data, countering traffic analysis nor data
minimisation. <xref target="RFC6973"/>  
And in all cases, there will remain some privacy-relevant information
that is inevitably disclosed by protocols.  
</t>

<t>
It is nonetheless timely to revisit the security and privacy properties of our
standards.  
The IETF will work to mitigate the
technical parts of the pervasive monitoring threat, just as we
do for other protocol vulnerabilities.  
The ways in
which IETF protocols mitigate pervasive monitoring
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 pervasive monitoring, 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 addressed?" </t>

<t>While pervasive monitoring is an attack, other forms of monitoring can be
beneficial and not part of any attack, e.g. network management functions
monitor packets or flows, anti-spam mechanisms see mail message content and
monitoring can even be a mitigation for pervasive monitoring in the case of
Certificate Transparency. <xref target="RFC6962"/> There is though a clear
potential for monitoring mechanisms to be abused for pervasive monitoring, so
this tension needs careful consideration in protocol design.  Making networks
unmanageable to mitigate pervasive monitoring is not an acceptable outcome,
but ignoring pervasive monitoring 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>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 specify all layers of the
protocol stack. And  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 pervasive monitoring, if it 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 
   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 by 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 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
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,
Bjoern Hoehrmann,
Phillip Hallam-Baker,
Russ Housley,
Joel Jaeggli,
Stephen Kent,
Eliot Lear,
Barry Leiba,
Ted Lemon,
Subrahamian Moonesamy,
Erik Nordmark,
Pete Resnick,
Peter Saint-Andre,
Andrew Sullivan,
Sean Turner,
and
Stefan Winter.

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>