Internet Engineering Task Force (IETF) T. Hardie
Request for Comments: 8165 May 2017
Category: Informational
ISSN: 2070-1721
Design Considerations for Metadata Insertion
Hardie Informational [Page 1]
RFC 8165 Design Considerations for Metadata Insertion May 2017
Table of Contents
1. Introduction
To minimize the risks associated with pervasive surveillance, it is necessary for the Internet technical community to address the vulnerabilities exploited in the attacks documented in [RFC7258] and the threats described in [RFC7624]. The goal of this document is to address a common design pattern that emerges from the increase in encryption: explicit association of metadata that would previously have been inferred from the plaintext protocol.
2. Terminology
This document makes extensive use of standard security and privacy terminology; see [RFC4949] and [RFC6973]. Readers should be familiar with the terms defined in [RFC6973], including "Eavesdropper", "Observer", "Initiator", "Intermediary", "Recipient", "Attack" (in a privacy context), "Correlation", "Fingerprint", "Traffic Analysis", and "Identifiability" (and related terms). Readers should also be familiar with terms that are specific to the attacks discussed in [RFC7624], including "Pervasive Attack", "Passive Pervasive Attack", "Active Pervasive Attack", "Observation", "Inference", and "Collaborator".
3. Design Pattern
One of the core mitigations for the loss of confidentiality in the presence of pervasive surveillance is data minimization, which limits the amount of data disclosed to those elements absolutely required to complete the relevant protocol exchange. When data minimization is in effect, some information that was previously available may be removed from specific protocol exchanges. The information may be removed explicitly (for example, by a browser suppressing cookies during private modes) or by other means. As noted in [RFC7624], some topologies that aggregate or alter the network path also act to reduce the ease with which metadata is available to eavesdroppers.
Hardie Informational [Page 2]
RFC 8165 Design Considerations for Metadata Insertion May 2017
In some cases, other actors within a protocol context will continue to have access to the information that has been thus withdrawn from specific protocol exchanges. If those actors attach the information as metadata to those protocol exchanges, the confidentiality effect of data minimization is lost.
4. Advice
Avoid inserting metadata to restore information that would otherwise be unavailable to later participants in a protocol exchange. It contributes to the overall loss of confidentiality for the Internet and trust in the Internet as a medium. Do not add metadata to flows at intermediary devices unless a positive affirmation of approval for restoration has been received from the actor whose data will be added.
Hardie Informational [Page 3]
RFC 8165 Design Considerations for Metadata Insertion May 2017
From a protocol perspective, in other words, this approach would be a minor change from RFC 7871, would be as fully featured, and would provide better privacy properties than the on-path update mechanism RFC 7871 provides. The next section examines why, despite this, deployment considerations have sometimes trumped cleaner designs.
5. Deployment Considerations
There are a few common tensions associated with the deployment of systems that restore metadata. The first is the trade-off in speed of deployment for different actors. The Forwarded HTTP Extension in [RFC7239] provides an example of this. When used with a proxy, it restores information related to the original requesting party, thus allowing a responding server to tailor responses according to the original party's region, network, or other characteristics associated with the identity. It would, of course, be possible for the originating client to add this data itself, after using STUN [RFC5389] or a similar mechanism to first determine the information to declare. This would require, however, full specification and adoption of this mechanism by the end systems. It would not be available at all during this period and would thereafter be limited to systems that have been upgraded to include it. The long tail of browser deployments indicates that many systems might go without upgrades for a significant period of time. The proxy infrastructure, in contrast, is commonly under more active management and represents a much smaller number of elements; this impacts both the general deployment difficulty and the number of systems that the origin server must trust.
Hardie Informational [Page 4]
RFC 8165 Design Considerations for Metadata Insertion May 2017
There are also tensions with latency of operation. For example, where the end system does not initially know the information that would be added by on-path devices, it must engage the protocol mechanisms to determine it. Determining a public IP address to include in a locally supplied header might require a STUN exchange, and the additional latency of this exchange discourages deployment of host-based solutions. To minimize this latency, engaging those mechanisms may need to be done in parallel with or in advance of the core protocol exchanges with which this metadata would be supplied.
6. IANA Considerations
This document makes no request of IANA.
7. Security Considerations
This memorandum describes a design pattern emerging from responses to the attacks described in [RFC7258]. Continued use of this design pattern, which uses mid-flow devices to restore metadata, lowers the impact of mitigations to that attack.
Hardie Informational [Page 5]
RFC 8165 Design Considerations for Metadata Insertion May 2017 8. References 8.1. Normative References[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
8.2. Informative References
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
Hardie Informational [Page 6]
RFC 8165 Design Considerations for Metadata Insertion May 2017
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.