Changeset 1588

Timestamp:

12/03/12 08:19:08 (10 years ago)

Author:

fielding@…

Message:

clean up some of the nonsense in security considerations

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (8 diffs)
• p1-messaging.xml (modified) (3 diffs)

draft-ietf-httpbis/latest/p1-messaging.html

@@ -460 +460 @@
   } 
   @bottom-center {
-       content: "Expires September 12, 2012"; 
+       content: "Expires September 13, 2012"; 
   } 
   @bottom-right {
@@ -502 +502 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-03-11">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-03-12">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -534 +534 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 12, 2012</td>
+               <td class="left">Expires: September 13, 2012</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">March 11, 2012</td>
+               <td class="right">March 12, 2012</td>
             </tr>
          </tbody>
@@ -572 +572 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 12, 2012.</p>
+      <p>This Internet-Draft will expire on September 13, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -706 +706 @@
                <li>8.3&nbsp;&nbsp;&nbsp;<a href="#attack.pathname">Attacks Based On File and Path Names</a></li>
                <li>8.4&nbsp;&nbsp;&nbsp;<a href="#dns.related.attacks">DNS-related Attacks</a></li>
-               <li>8.5&nbsp;&nbsp;&nbsp;<a href="#attack.proxies">Proxies and Caching</a></li>
+               <li>8.5&nbsp;&nbsp;&nbsp;<a href="#attack.intermediaries">Intermediaries and Caching</a></li>
                <li>8.6&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></li>
-               <li>8.7&nbsp;&nbsp;&nbsp;<a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li>
             </ul>
          </li>
@@ -2643 +2642 @@
       <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Abuse of Server Log Information</a></h2>
       <p id="rfc.section.8.2.p.1">A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects
-         of interest. This information is clearly confidential in nature and its handling can be constrained by law in certain countries.
-         People using HTTP to provide data are responsible for ensuring that such material is not distributed without the permission
-         of any individuals that are identifiable by the published results.
+         of interest. In particular, log information gathered at an intermediary often contains a history of user agent interaction,
+         across a multitude of sites, that can be traced to individual users.
+      </p>
+      <p id="rfc.section.8.2.p.2">HTTP log information is confidential in nature; its handling is often constrained by laws and regulations. Log information
+         needs to be securely stored and appropriate guidelines followed for its analysis. Anonymization of personal information within
+         individual entries helps, but is generally not sufficient to prevent real log traces from being re-identified based on correlation
+         with other access characteristics. As such, access traces that are keyed to a specific client should not be published even
+         if the key is pseudonymous.
+      </p>
+      <p id="rfc.section.8.2.p.3">To minimize the risk of theft or accidental publication, log information should be purged of personally identifiable information,
+         including user identifiers, IP addresses, and user-provided query parameters, as soon as that information is no longer necessary
+         to support operational needs for security, auditing, or fraud control.
       </p>
       <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2>
@@ -2661 +2669 @@
          validity of an IP number/DNS name association unless the response is protected by DNSSec (<a href="#RFC4033" id="rfc.xref.RFC4033.1"><cite title="DNS Security Introduction and Requirements">[RFC4033]</cite></a>).
       </p>
-      <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="attack.proxies" href="#attack.proxies">Proxies and Caching</a></h2>
-      <p id="rfc.section.8.5.p.1">By their very nature, HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Compromise
-         of the systems on which the proxies run can result in serious security and privacy problems. Proxies have access to security-related
-         information, personal information about individual users and organizations, and proprietary information belonging to users
-         and content providers. A compromised proxy, or a proxy implemented or configured without regard to security and privacy considerations,
-         might be used in the commission of a wide range of potential attacks.
-      </p>
-      <p id="rfc.section.8.5.p.2">Proxy operators need to protect the systems on which proxies run as they would protect any system that contains or transports
-         sensitive information. In particular, log information gathered at proxies often contains highly sensitive personal information,
-         and/or information about organizations. Log information needs to be carefully guarded, and appropriate guidelines for use
-         need to be developed and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section&nbsp;8.2</a>).
-      </p>
-      <p id="rfc.section.8.5.p.3">Proxy implementors need to consider the privacy and security implications of their design and coding decisions, and of the
-         configuration options they provide to proxy operators (especially the default configuration).
-      </p>
-      <p id="rfc.section.8.5.p.4">Users of a proxy need to be aware that proxies are no more trustworthy than the people who run them; HTTP itself cannot solve
+      <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="attack.intermediaries" href="#attack.intermediaries">Intermediaries and Caching</a></h2>
+      <p id="rfc.section.8.5.p.1">By their very nature, HTTP intermediaries are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks.
+         Compromise of the systems on which the intermediaries run can result in serious security and privacy problems. Intermediaries
+         have access to security-related information, personal information about individual users and organizations, and proprietary
+         information belonging to users and content providers. A compromised intermediary, or an intermediary implemented or configured
+         without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks.
+      </p>
+      <p id="rfc.section.8.5.p.2">Intermediaries that contain a shared cache are especially vulnerable to cache poisoning attacks.</p>
+      <p id="rfc.section.8.5.p.3">Implementors need to consider the privacy and security implications of their design and coding decisions, and of the configuration
+         options they provide to operators (especially the default configuration).
+      </p>
+      <p id="rfc.section.8.5.p.4">Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve
          this problem.
       </p>
@@ -2693 +2697 @@
       <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
       </p>
-      <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a>&nbsp;<a id="attack.DoS" href="#attack.DoS">Denial of Service Attacks on Proxies</a></h2>
-      <p id="rfc.section.8.7.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>
       <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
       <p id="rfc.section.9.p.1">This edition of HTTP builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068.5">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.3">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -3706 +3706 @@
    A server is in the position to save personal data about a user's
    requests which might identify their reading patterns or subjects of
-   interest. This information is clearly confidential in nature and its
-   handling can be constrained by law in certain countries. People using
-   HTTP to provide data are responsible for ensuring that
-   such material is not distributed without the permission of any
-   individuals that are identifiable by the published results.
+   interest.  In particular, log information gathered at an intermediary
+   often contains a history of user agent interaction, across a multitude
+   of sites, that can be traced to individual users.
+</t>
+<t>
+   HTTP log information is confidential in nature; its handling is often
+   constrained by laws and regulations.  Log information needs to be securely
+   stored and appropriate guidelines followed for its analysis.
+   Anonymization of personal information within individual entries helps,
+   but is generally not sufficient to prevent real log traces from being
+   re-identified based on correlation with other access characteristics.
+   As such, access traces that are keyed to a specific client should not
+   be published even if the key is pseudonymous.
+</t>
+<t>
+   To minimize the risk of theft or accidental publication, log information
+   should be purged of personally identifiable information, including
+   user identifiers, IP addresses, and user-provided query parameters,
+   as soon as that information is no longer necessary to support operational
+   needs for security, auditing, or fraud control.
 </t>
 </section>
@@ -3745 +3760 @@
 </section>
 
-<section title="Proxies and Caching" anchor="attack.proxies">
-<t>
-   By their very nature, HTTP proxies are men-in-the-middle, and
+<section title="Intermediaries and Caching" anchor="attack.intermediaries">
+<t>
+   By their very nature, HTTP intermediaries are men-in-the-middle, and
    represent an opportunity for man-in-the-middle attacks. Compromise of
-   the systems on which the proxies run can result in serious security
-   and privacy problems. Proxies have access to security-related
+   the systems on which the intermediaries run can result in serious security
+   and privacy problems. Intermediaries have access to security-related
    information, personal information about individual users and
    organizations, and proprietary information belonging to users and
-   content providers. A compromised proxy, or a proxy implemented or
-   configured without regard to security and privacy considerations,
-   might be used in the commission of a wide range of potential attacks.
-</t>
-<t>
-   Proxy operators need to protect the systems on which proxies run as
-   they would protect any system that contains or transports sensitive
-   information. In particular, log information gathered at proxies often
-   contains highly sensitive personal information, and/or information
-   about organizations. Log information needs to be carefully guarded, and
-   appropriate guidelines for use need to be developed and followed.
-   (<xref target="abuse.of.server.log.information"/>).
-</t>
-<t>
-   Proxy implementors need to consider the privacy and security
+   content providers. A compromised intermediary, or an intermediary
+   implemented or configured without regard to security and privacy
+   considerations, might be used in the commission of a wide range of
+   potential attacks.
+</t>
+<t>
+   Intermediaries that contain a shared cache are especially vulnerable
+   to cache poisoning attacks.
+</t>
+<t>
+   Implementors need to consider the privacy and security
    implications of their design and coding decisions, and of the
-   configuration options they provide to proxy operators (especially the
+   configuration options they provide to operators (especially the
    default configuration).
 </t>
 <t>
-   Users of a proxy need to be aware that proxies are no more trustworthy than
+   Users need to be aware that intermediaries are no more trustworthy than
    the people who run them; HTTP itself cannot solve this problem.
 </t>
@@ -3807 +3818 @@
    phrases, header field-names, and body chunks) &SHOULD; be limited by
    implementations carefully, so as to not impede interoperability.
-</t>
-</section>
-
-<section title="Denial of Service Attacks on Proxies" anchor="attack.DoS">
-<t>
-   They exist. They are hard to defend against. Research continues.
-   Beware.
 </t>
 </section>