Internet DRAFT - draft-nottingham-transport-metadata-impact
draft-nottingham-transport-metadata-impact
Network Working Group M. Nottingham
Internet-Draft
Intended status: Informational J. Hall
Expires: February 25, 2016 CDT
N. ten Oever
Article19
W. Seltzer
W3C
August 24, 2015
User Impact of Transport Metadata
draft-nottingham-transport-metadata-impact-00
Abstract
This draft attempts to identify potential impacts associated with
new, extensible metadata facilities in Internet protocols, and
suggests possible mitigations. Its goal is to have the discussion of
these tradeoffs up-front, rather than after the development of such
mechanisms.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 25, 2016.
Copyright Notice
Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Nottingham, et al. Expires February 25, 2016 [Page 1]
Internet-Draft Transport Metadata Impact August 2015
carefully, as they describe your rights and restrictions with respect
to 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 are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Potential Impact . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Security and Privacy . . . . . . . . . . . . . . . . . . 3
2.2. Network Neutrality . . . . . . . . . . . . . . . . . . . 4
3. Possible Mitigations . . . . . . . . . . . . . . . . . . . . 4
3.1. Constrained Vocabulary . . . . . . . . . . . . . . . . . 4
3.2. Transparency . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. Informative References . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Recently, there has been an increasing amount of discussion in the
IETF about adorning protocol flows with metadata about the network's
state for consumption by applications, as well as that of the
application in order to inform decisions in the network. For
examples, see [I-D.nottingham-gin],
[I-D.sprecher-mobile-tg-exposure-req-arch] and
[I-D.hildebrand-spud-prototype].
These discussions are being at least partially motivated by the
increasing use of encryption, both in deployment (thanks to the
Snowden revelations) and standards (thanks in some part to [RFC7258],
[IAB-confidentiality], and [TAG-securing-web]); while it's becoming
widely accepted that networks don't have legitimate need to access
the content of flows in most cases, they still wish to meet certain
use cases that require more information.
For example, networks may wish to communicate their state to
applications, so that link limitations and transient problems can be
accounted for in applications, by doing things like degrading (or
improving) video streaming quality.
Applications also need to give enough information to networks to
enable proper function; e.g., packets in UDP flows need to be
associated to be able to cleanly transit NAT and firewalls. See
[I-D.trammell-stackevo-newtea] and [I-D.hardie-spud-use-cases] for
more discussion.
Nottingham, et al. Expires February 25, 2016 [Page 2]
Internet-Draft Transport Metadata Impact August 2015
At the same time, it has been widely noted that "metadata" in various
forms can be profoundly sensitive information, particularly when
aggregated into large sets over extensive periods of time.
Indeed, much of the effort in combatting pervasive monitoring (as per
[RFC7258]) has focused on minimizing metadata in existing, known
protocols (such as TLS and HTTP).
Any new metadata facility, then - whether it be introduced to an
existing protocol, or as part of a new one - needs to be carefully
scrutinized and narrowly tailored to conservatively emit metadata.
Of particular concern is an observed trend towards arbitrarily
extensible metadata.
This draft attempts to identify potential impacts associated with new
metadata facilities in Internet protocols, and suggest possible
mitigations. Its goal is to initiate a discussion of these tradeoffs
up-front, rather than waiting until after the development of such
mechanisms.
Adding metadata to protocols is not an inherent harm - i.e., there
are some legitimate uses of metadata, particularly if it eases the
adoption of encrypted protocols or aligns well with both the
interests of users and service or network operations, e.g., traffic
management on mobile networks. However, the balance between the
interests of constituents like end users, content providers and
network operators needs to be carefully considered.
2. Potential Impact
2.1. Security and Privacy
It's been established [Injection] that many network operators inject
HTTP headers into requests, in order to identify their customers
using a unique identifier, thereby allowing "third-party advertisers
and websites to assemble a deep, permanent profile of visitors' web
browsing habits without their consent." [X-UIDH]
In doing so, these networks are taking advantage of a relatively
unconstrained extension point in the HTTP protocol - header fields.
While HTTP header fields do require registration [RFC3864], the
requirements are lax, and fields are often used without registration,
because there is no technical enforcement of the requirements, due to
HTTP's policy of ignoring unrecognized header fields [RFC7230].
HTTP header fields can be made a protected end-to-end facility by
using HTTPS, avoiding the risk of such injection. A new transport
Nottingham, et al. Expires February 25, 2016 [Page 3]
Internet-Draft Transport Metadata Impact August 2015
metadata facility that explicitly allows any node on the path to add
arbitrary metadata cannot.
Well-intentioned metadata can also put the user at substantial risk
without careful consideration. For example, if a Web browser
"labels" flows based upon what they contain (e.g., "video", "image",
"interactive"), an observer on the network path - including pervasive
ones - can more effectively perform traffic analysis to determine
what the user is doing. Similarly, metadata adornment might reveal
sensitive information; for example the Server Name Indicator (SNI) in
the TLS handshake would reveal if a web visitor intends to go to
"bannedcontent.github.com" versus "kitties.github.com".
Standardizing an extensible transport metadata mechanism could also
trigger various jurisdictions to define and require insertion of in-
band metadata, an extension of current practices [AU-data-retention].
While the IETF would not be directly responsible for such an outcome,
it is notable that in the past we've explicitly said we won't serve
conceptually similar use cases [RFC1984].
2.2. Network Neutrality
There is obvious potential for network neutrality impact from a
mechanism that allows networks to communicate with endpoints about
flows.
For example, if a network can instruct content servers to throttle
back bandwidth available to users for video based upon a commercial
arrangement (or lack thereof), the network can achieve their goals
without directly throttling traffic, thereby offering the potential
to circumvent a regulatory regime that's designed to effect network
neutrality.
While the IETF has not take as firm a stance on network neutrality as
it has for Pervasive Monitoring (for good reasons, since network
neutrality problems are at their heart a sign of market failure, not
a technical issue), new metadata facilities that enable existing
regulatory regimes - thereby upsetting "the tussle" - must be
carefully considered.
3. Possible Mitigations
3.1. Constrained Vocabulary
Much of the potential for harm above comes about because a transport-
level metadata mechanism effectively becomes a side channel for
arbitrary data, for use by any node on the path. The risks of
Nottingham, et al. Expires February 25, 2016 [Page 4]
Internet-Draft Transport Metadata Impact August 2015
questionable use could be mitigated by constraining the data that's
allowed in this side channel.
In other words, if the network doesn't have a means of inserting a
unique identifier for customers, they won't be able to do so. If
notification of constrained network conditions takes place using
well-defined terms, regulatory regimes can be adjusted to achieve
desired outcomes. And, information about application semantics can
be carefully vetted for security considerations before being included
in transport metadata.
One way to technically enforce such constraints would be to require
nodes to silently drop non-standard metadata. Another would be to
not make metadata extensible at all.
Naturally, this would constrain the ability of networks and
applications to add new terms to metadata, thereby requiring more
careful thought to go into the metadata that is standardised "up
front."
3.2. Transparency
Many proposals for transport metadata assert that it will be
encrypted, to improve security. While well-intentioned, it also
creates an opaque side channel with a third party (the first and
second being the endpoints).
The effect of of such designs should be carefully considered before
standardisation; it may be that the community is better served by
keeping this metadata "in the clear", albeit possibly with some form
of authentication and integrity available (or required).
4. Security Considerations
This document describes security and privacy aspects of metadata
adornment to internet protocols that protocol designers should
consider.
5. Informative References
[AU-data-retention]
Keane, B., "Your guide to the data retention debate: what
it is and why it's bad", March 2015,
<http://www.crikey.com.au/2015/03/18/your-guide-to-the-
data-retention-debate-what-it-is-and-why-it's-bad/>.
Nottingham, et al. Expires February 25, 2016 [Page 5]
Internet-Draft Transport Metadata Impact August 2015
[I-D.hardie-spud-use-cases]
Hardie, T., "Use Cases for SPUD", draft-hardie-spud-use-
cases-01 (work in progress), February 2015.
[I-D.hildebrand-spud-prototype]
Hildebrand, J. and B. Trammell, "Substrate Protocol for
User Datagrams (SPUD) Prototype", draft-hildebrand-spud-
prototype-03 (work in progress), March 2015.
[I-D.nottingham-gin]
Nottingham, M., "Granular Information about Networks",
draft-nottingham-gin-00 (work in progress), July 2014.
[I-D.sprecher-mobile-tg-exposure-req-arch]
Jain, A., Terzis, A., Sprecher, N., Swaminathan, S.,
Smith, K., and G. Klas, "Requirements and reference
architecture for Mobile Throughput Guidance Exposure",
draft-sprecher-mobile-tg-exposure-req-arch-01 (work in
progress), February 2015.
[I-D.trammell-stackevo-newtea]
Trammell, B., "Thoughts a New Transport Encapsulation
Architecture", draft-trammell-stackevo-newtea-01 (work in
progress), May 2015.
[IAB-confidentiality]
Internet Architecture Board, "IAB Statement on Internet
Confidentiality", November 2014,
<http://www.iab.org/2014/11/14/
iab-statement-on-internet-confidentiality/>.
[Injection]
Ammari, N., Björksten, G., Micek, P., and D.
Olukotun, "The Rise of Mobile Tracking Headers: How Telcos
Around the World Are Threatening Your Privacy", August
2015, <https://www.accessnow.org/blog/2015/08/17/read-our-
new-report-on-the-troubling-rise-of-tracking-headers-
worldwide2>.
[RFC1984] IAB and , "IAB and IESG Statement on Cryptographic
Technology and the Internet", RFC 1984, DOI 10.17487/
RFC1984, August 1996,
<http://www.rfc-editor.org/info/rfc1984>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004,
<http://www.rfc-editor.org/info/rfc3864>.
Nottingham, et al. Expires February 25, 2016 [Page 6]
Internet-Draft Transport Metadata Impact August 2015
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", RFC
7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.
[TAG-securing-web]
W3C Technical Architecture Group, "Securing the Web",
January 2015, <http://www.w3.org/2001/tag/doc/web-https>.
[X-UIDH] Hoffman-Andrews, J., "Verizon Injecting Perma-Cookies to
Track Mobile Customers, Bypassing Privacy Controls",
November 2014, <https://www.eff.org/deeplinks/2014/11/
verizon-x-uidh>.
Authors' Addresses
Mark Nottingham
Email: mnot@mnot.net
URI: https://www.mnot.net/
Joseph Lorenzo Hall
CDT
Email: joe@cdt.org
URI: https://cdt.org/
Niels ten Oever
Article19
Email: niels@article19.org
URI: https://www.article19.org/
Wendy Seltzer
W3C
Email: wseltzer@w3.org
URI: http://wendy.seltzer.org/
Nottingham, et al. Expires February 25, 2016 [Page 7]
