DRAFT TAG Finding -- no current standing
This finding documents the TAG's position on the use of encryption on the Web.
Over the last 25 years, the Web has grown into a platform for much of the world's communication, whether it be information sharing, community building, commerce, education, social networking, or underpinning applications.
In meeting these needs, the Web's trustworthiness has become critical to its success. If a person cannot trust that they are communicating with their intended party, they won't use the Web to shop; if they cannot be assured that their news isn't modified in transit, they won't be as informed. If someone cannot be assured that they're talking only the intended recipients, they will avoid social networking.
These important properties of authentication, integrity and confidentiality are best -- if not perfectly -- provided to the Web platform by Transport Layer Security (TLS), through use of HTTPS URLs.
In the past, Web sites have deployed HTTPS rarely; often, when financial transactions take place. More recently, however, it has become apparent that nearly all activity on the Web can be considered sensitive, since it now plays such a central role in everyday life. Attacks like pervasive monitoring only increase the urgency and relevance of establishing a baseline for trust on the entire Web.
Therefore, the TAG finds that the Web platform must actively prefer secure origins -- typically by encouraging use of HTTPS URLs instead of HTTP. Furthermore, the end-to-end nature of TLS encryption must not be compromised on the Web platform, in order to preserve trust.
We recognize that end-to-end encryption will not solve all -- or even many -- security problems in the Web platform. However, it does serve as an important and necessary baseline for further developments. This is especially true as the platform becomes more powerful, and thus more dangerous to use "in the clear".
Likewise, we realize that transitioning to a secure origin may not be easy for all sites. While the CPU overhead of TLS has been largely overcome by advances in processor technology, the Web platform itself makes changing schemes difficult, both because URLs themselves need to change, and because the URL scheme is also used to trigger different behavior in many platform features. These problems ought to be viewed as opportunities for improvement in the platform, rather than reasons to stop adoption of encryption.
We acknowledge that in some cases, networks currently rely upon cleartext access to network flows to impose policy (e.g., filtering) and optimize content. However, we believe that policy imposition is best performed at the endpoints of a connection. Furthermore, providing network-based optimization is not a valid reason to violate trust on the Web, and should be made unnecessary in the medium-to-long term by other improvements in the Web platform (see the Web Performance Working Group, for example).
Finally, some have expressed fear that an encrypted Web will benefit those with purposes that are distasteful or even dangerous. We reject these arguments; the Web is a tool that can be used to many ends, and possible misuse does not imply that the tool should be so limited as to not fit its purpose.
The rest of this document explains how the TAG expects this policy to be implemented.
This section contains guidelines for those writing Web platform specifications, including -- but not limited to -- W3C Working Groups.
New Web platform features that provide access to or potentially carry sensitive data only do so when used with secure origins.
"Sensitive data" includes (but is not limited to) personally identifying information (PII), credentials, payment instruments, that generated by environmental sensors and receptors (e.g., cameras, accelerometers, microphones), native APIs or "browser chrome."
Note that facilities that carry such information -- such as new network access mechanisms, or other generic functions with access to network data -- are also constrained by this requirement.
A secure origin is one which meets one of the following tests:
- The uri-scheme is "https"
- The uri-scheme is "wss"
- The uri-scheme is "file"
- The uri-host is or falls within the "localhost." domain
- The uri-host is within a loopback special-purpose IP address range; i.e. 127/8 or ::1/128
Other kinds of origins can be considered secure with appropriate TAG review.
Here, "new" features are those that have not been previously available on the Web platform (i.e., a "1.0" feature), or revised features that are not backwards-compatible with a previous version (e.g., a "2.0" feature). It does not include backwards-compatible revisions to existing features.
For example, Service Workers is being developed in this manner; it is a new platform feature, and because it can intercept requests and responses and modify them, it has the potential to carry sensitive data.
Web platform features that already exist should be examined to determine whether they provide access to or carry sensitive data, as described above.
Such features that are not widely implemented and/or used should either be immediately withdrawn (i.e., specification recinded and removed from implementations, as appropriate).
When such features are widely implemented and used, they should be deprecated; that is, the specification should be modified with a note to the effect that the feature does not conform to this policy, and may be withdrawn in the future. Simultaneously, a plan should be developed to offer a conformant revision of the feature, ideally as part of a larger revision that provides better functionality.
For example, the Geolocation API provides access to sensitive data (the user's location), and yet is available to non-secure origins. Since it is both widely-implemented and used, the appropriate action will be to modify the specification immediately, and commence planning on a new major version of the API which requires secure origins, along with other improvements.
This section documents related architectural issues for further consideration by the TAG or other parties as appropriate.
Many of the problems caused by transitioning from HTTP to HTTPS URLs is caused by the use of a URL scheme to indicate security properties.
In particular, changing the scheme of URLs themselves causes friction; since identifiers are meant to be long-lasting, offsite references will break, whereas onsite content needs to be rewritten.
While redirecting HTTP to HTTPS can help ease this transition, it does not have ideal security properties, even when mitigated by HSTS.
Furthermore, some Web platform features use the URL scheme as a coarse-grained indication of security intent, causing further friction against the transition. For example, the HTTP Referer header field is not sent for HTTPS URLs; the Referrer Policy specification is attempting to address this limitation.
This bears examination; in particular:
- Should URL new schemes indicate security properties in their names?
- What practices should sites use (and avoid) when transitioning from HTTP to HTTPS?
- What additional mechanisms could help sites transition?
- What security decisions in the platform should be decoupled from the URL scheme (e.g., into Content Security Policy)?
Establishing trust when an origin is not unique -- such as when addresses in private address space like "192.168.1.10" are in use -- is difficult on today's Web.
Typically, a self-signed certificate is used in these situations, causing browsers to warn users -- and such warnings are usually clicked through, eroding the user's model of security.
While IPv6 might make such addresses obsolete in the longer term, a more immediate solution is necessary.
Fundamentally, TLS is an end-to-end protocol; that is, it protects communication between two parties. On the Web, these are the user and the origin.
However, this two-party trust model can be -- and is already -- circumvented for users in two major ways:
- Inserting a new root in the user's trust store (i.e., "installing a certificate authority")
- Providing the user with a so-called "split browser" that terminates TLS in the network
While these might be legitimate approaches to addressing certain use cases, the power conveyed by them is often not apparent to the user.
If we truly believe that policy is best imposed at the endpoints, and that the Web is a platform, we ought to consider what facilities, if any, the platform should provide for this purpose.
This finding builds upon and explicitly acknowledges the Internet Architecture Board's Statement on Internet Confidentiality and the Chromium Team's "Prefer Secure Origins For Powerful New Features".