Changeset 1588 for draft-ietf-httpbis/latest/p1-messaging.xml

Timestamp:

Mar 12, 2012, 1:19:08 AM (8 years ago)

Author:

fielding@…

Message:

clean up some of the nonsense in security considerations

File:

• draft-ietf-httpbis/latest/p1-messaging.xml (modified) (3 diffs)

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>