RFC 8165

Design Considerations for Metadata Insertion

📅 published May 2017, from ietf

RFC 8165: Design Considerations for Metadata Insertion 💖

okay bestie, first the paperwork 📎 This is RFC 8165, called Design Considerations for Metadata Insertion. T. Hardie wrote it and it came out in May 2017. It's filed as Informational, which means it's advice and not a standards-track spec 🌸 It's an IETF product with ISSN 2070-1721. It doesn't obsolete or update any other RFCs, so it's a solo act ✨

Abstract

The IAB put out RFC 7624 after a bunch of revelations about pervasive attacks on Internet communications 😭 This doc looks at what happens when protocol designs attach metadata to encrypted flows 🔐 Its big takeaway: designs that share metadata only through explicit actions at the host are better than designs where middleboxes insert the metadata 💅

Status of This Memo

Heads up, this one is NOT an Internet Standards Track specification ❌ It's published purely for informational purposes 🦋

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not everything the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for the details 🤓

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc8165 💌

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 🎀

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, found at http://trustee.ietf.org/license-info, as in effect on the date of publication. Please read those carefully because they spell out your rights and restrictions for this document 📜 Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🧾

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Design Pattern ..................................................2
   4. Advice ..........................................................3
   5. Deployment Considerations .......................................4
   6. IANA Considerations .............................................5
   7. Security Considerations .........................................5
   8. References ......................................................6
      8.1. Normative References .......................................6
      8.2. Informative References .....................................6
   Acknowledgements ...................................................7
   Author's Address ...................................................7

1. Introduction ✨

To cut down the risks from pervasive surveillance, the Internet technical community needs to address the vulnerabilities used in the attacks documented in [RFC7258], along with the threats described in [RFC7624] 🕵️‍♀️ This doc targets a common design pattern that shows up as encryption spreads: explicitly attaching metadata that used to be inferred from the plaintext protocol 🧩

2. Terminology 📚

This doc uses a ton of standard security and privacy terminology, so see [RFC4949] and [RFC6973] 🤓 Readers should know 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). You should also get comfy with the terms specific to the attacks discussed in [RFC7624]: "Pervasive Attack", "Passive Pervasive Attack", "Active Pervasive Attack", "Observation", "Inference", and "Collaborator" 🧠

3. Design Pattern 🎀

One of the core mitigations for losing confidentiality under pervasive surveillance is data minimization 🫧 It limits the data disclosed to only the elements absolutely required to complete the relevant protocol exchange. When data minimization is in effect, some information that was previously available may get removed from specific protocol exchanges. That removal can be explicit (like a browser suppressing cookies during private modes) or happen by other means. As [RFC7624] notes, some topologies that aggregate or alter the network path also make metadata harder for eavesdroppers to get at 🧱

Other actors within a protocol context may still have access to the information that was withdrawn from those exchanges 👀 If they attach that information back as metadata to those protocol exchanges, the confidentiality effect of data minimization is lost 💔

Restoring information is especially tempting at systems that weren't primarily deployed to increase confidentiality 🙈 A proxy providing compression, for example, may want to restore the identity of the requesting party, and a VPN system used for channel security may think the origin IP should be restored too. Actors considering restoring metadata may believe they understand the relevant privacy considerations, or they may assume that since the service's primary purpose wasn't privacy-related, none exist 🙃 Examples of this design pattern include [RFC7239] and [RFC7871] 🌈

7. Security Considerations 🔐

okay this one is SERIOUS bestie 😭 but also lowkey iconic. This memo is describing a design pattern that came out of responding to the attacks in [RFC7258] 🛡️ Using mid-flow devices to restore metadata is the pattern, and if you keep using it, it makes the mitigations for that attack hit way less hard. 💅

Also, some emergency service recipients, like PSAPs (Public Safety Answering Points) 🚨, may prefer data that the network gives them over data that comes from the end system. Why? Because an end system could send false data to attack others or eat up resources 💀. Yes, the PSAP's data is usually more coarse than what the end system has, but false data can put lives at risk, and that is the whole ballgame 🥺🫶.

8. References 📚

8.1. Normative References

8.2. Informative References

Acknowledgements 🫶

This document is a little bit of a group project 🧚 It's partly built on the work that happened on the perpass mailing list and at the STRINT workshop [RFC7687] ✨. The text was first developed by the IAB's Privacy and Security Program before it was submitted to the IETF 💜. It also got a super thorough review from Mohamed Boucadair 👑, so big thanks to him!

Author's Address 🎀

Ted Hardie

Email: ted.ietf@gmail.com

📦 where this page comes from