| Network Working Group | B. Kennish |
| Internet-Draft | Bennish.net |
| Intended status: Standards Track | October 5, 2014 |
| Expires: April 8, 2015 |
Trusted Linker Download Redirection (TLDR)
draft-bennish-http-tldr-00
This document describes an HTTP extension that allows user agents to verify downloaded data. It provides a standardised way for an HTTPS URL (assumed trustworthy) to redirect to a non-HTTPS URL and give the user agent extra information about the resulting output (e.g. a downloaded file.) Once that is retrieved, it can check whether or not the data has been modified since the trustworthy site checked it (e.g. altered during transit or as a result of the destination site having been compromised.)
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 April 8, 2015.
Copyright (c) 2014 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 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.
Transport Layer Security (TLS/SSL) [RFC-5246] can add an often much needed level of security to the Hypertext Transfer Protocol (HTTP) [RFC-2616] (a combination normally referred to as HTTPS) but the encryption algorithms are often too much of a strain for busy public file download servers, especially when arguably the data stream does not really need to be encrypted (the files are publicly accessible anyway).
As a result, servers providing public file downloads, even potentially dangerous file types such as those with executable code, scripts, etc., often do not deliver the files using HTTPS. However, this makes the downloads vulnerable to Man-in-the-Middle (MitM) attacks; an attacker could change the data during transit to serve the client with malware.
Trusted Linker Download Redirection (TLDR) describes a process by which an (assumed trustworthy) HTTPS URL can redirect to a non-HTTPS download URL and give the user agent extra information about the file so that, once downloaded, the agent can check whether the file is the same one that the trustworthy site verified.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]
The TLDR headers SHOULD only be sent by the Trusted Link web server with responses that use one of the following HTTP status codes:
Note that the permanent redirects (such as 301 "Moved Permanently" and 308 "Permanent Redirect") are not included in the list. These status codes instruct user agents to send all future requests to the URL provided in the "Location" header, thereby bypassing the Trusted Linker completely. It seems nonsensical to provide a TLDR service for the user agent's first request only!
Ideally, servers implementing TLDR should do so over the HTTPS protocol and not plain HTTP. If the headers are delivered without the safety that TLS/SSL provides, TLDR cannot detect Man in the Middle (MitM) attacks.
However, it does provides a bit of extra protection if used over plain HTTP assuming no MitM. For example, if the Final Destination server becomes compromised or for any other reason starts providing a different file to the one that it was before, the checksum will not match and this will be detected.
These HTTP response headers are all OPTIONAL but a web server must provide at least one to be a Trusted Linker. It should provide as many of them as possible in order to give user agents the biggest choice. To avoid ambiguity, a web server MUST NOT return more than one TLDR header with the same name.
When more than one checksum is provided by the server, it is not recommended for a user agent to use more that one of the checksums provided. It should select one; preferably the checksum function considered most secure at the time. The method by which the user agent selects a hash function MAY be user configurable.
All checksums are calculated on the complete file contents. If the file is delivered to the client using any kind of transfer encoding (such as HTTP gzip, chunked, etc.), the checksums MUST be calculated on the decoded data. Any kind of transfer mechanism that results in ambiguous output data (such as "ASCII mode" FTP) is not supported.
The examples given below each show the server replying with a different value for the HTTP status code. This is just to illustrate the different codes that can use TLDR and bears no relationship to the checksum hash function used.
While the examples with the longer header values are shown split to multiple lines, this is to aid the readability of this document and it is recommended that the actual header values are kept on a single line.
Location-Checksum-MD5 = "Location-Checksum-MD5: " md5-checksum
md5-checksum should be a string giving the expected 128-bit MD5 message digest for the resulting downloaded file (see [RFC-1321]).
HTTP/1.0 302 Moved Temporarily Location: http://www.example.com/files/download.tar.gz Location-Checksum-MD5: ccca8352847856cd4c2df77ce675de2b
Location-Checksum-SHA1 = "Location-Checksum-SHA1: " sha1-checksum
sha1-checksum should be a string giving the expected 160bit SHA1 message digest for the resulting downloaded file (see [RFC-3174]).
HTTP/1.1 302 Found Location: http://www.example.com/files/download.tar.gz Location-Checksum-SHA1: d98eaf66de93d9512958d6c7f5ed58d059dea53f
Location-Checksum-SHA256 = "Location-Checksum-SHA256: " sha256-checksum
sha256-checksum should be a string giving the expected 256bit SHA-256 message digest for the resulting downloaded file (see [RFC-6234]).
HTTP/1.1 303 See Other Location: http://www.example.com/files/download.tar.gz Location-Checksum-SHA256: d9c30fccbfd25469b41c1e2c68b3b1a8f2a241e1808 07d6beb3bc63ddfef6ff2
Location-Checksum-SHA512 = "Location-Checksum-SHA512: " sha512-checksum
sha512-checksum should be a string giving the expected 512bit SHA-512 message digest for the resulting downloaded file (see [RFC-6234]).
HTTP/1.1 307 Temporary Redirect Location: http://www.example.com/files/download.tar.gz Location-Checksum-SHA5126: a5555882da0419d98dd6b098e616aa66d7a5c13e54 9c2ab59dd7634ed07e379fafb4370925f65ff08d0cd50a19691acb6671a8d30b5298 0130dcc1bbfaf6a351
The user agent MAY display some kind of notification to the user upon starting a download using TLDR. However, it SHOULD NOT show any notification unless the Trusted Linker used HTTPS (because it might give the user a false sense of safety.)
Once the file has completely downloaded, the user agent calculates a checksum using its choice of the provided message digest algorithms and compares it to the one provided by the Trusted Linker. It then takes appropriate action depending on the result:
If the original TLDR checksum headers were sent using HTTPS, user agents MAY notify the user that the downloaded file was as expected according to the Trusted Linker. However, if they do, they SHOULD clearly provide the user with enough information about the Trusted Linker URL so that they can decide whether or not they do actually trust it (e.g. the fully qualified domain name). See the Security Considerations section for an explanation as to why this is necessary.
If the original TLDR checksum headers were sent over plain HTTP, user agents SHOULD NOT give any positive feedback to the user because of the possibility of a Man in the Middle (MitM) attack.
All the statements in this section apply even if the TLDR checksum headers were sent over plain HTTP. Any checksum mismatch is a cause for alarm.
If the checksums do not match, the user agent MUST give some kind of feedback to warn the user that something is wrong.
The user agent SHOULD also remove or quarantine the downloaded file to prevent it being used accidentally.
It is possible for a Trusted Linker to redirect to a Link that redirects again. There could be any number of redirections and any of the hops along this redirect chain could also provide new TLDR headers. If this happens, a user agent SHOULD simply ignore these headers. The first hop in a chain of redirects that provides TLDR is considered the most trust-worthy.
The author has created a prototype Add-on for the Mozilla Firefox web browser which demonstrates TLDR in action. Links to download the Add-on and some example download links that implement TLDR can be found at a page on the author's website [TLDR-Demo].
TLDR could be extended in the future to take advantage of other types of verification. Perhaps OpenPGP-related HTTP response headers could be used, possibly by providing one or more trusted public key fingerprints along with the URL of a signature for the file. I hope to explore this idea in future revisions of this document.
The author is aware of the existing acronym "TL;DR" meaning "Too Long; Didn't Read" and feels that it is appropriate that this proposed standard has the same acronym as it aptly describes the way most people probably feel when they see instructions on how to manually verify the integrity of their downloads such as these instructions on httpd.apache.org. The author would like to make it clear that he is not criticising these instructions in any way but instead pointing out that a manual verification process is quite lengthy and tedious.
[TO BE REMOVED: HTTP header fields should be registered within the "Message Headers" registry maintained at https://www.iana.org/assignments/message-headers/ ]
This document defines a number of HTTP header fields, so their associated registry entries shall be added according to the permanent registrations below (see [BCP90]):
+--------------------------+----------+----------+-------------+ | Header Field Name | Protocol | Status | Reference | +--------------------------+----------+----------+-------------+ | Location-Checksum-MD5 | http | standard | Section 4.1 | | Location-Checksum-SHA1 | http | standard | Section 4.2 | | Location-Checksum-SHA256 | http | standard | Section 4.3 | | Location-Checksum-SHA512 | http | standard | Section 4.4 | +--------------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". This specification defines a number of response header fields for the Hypertext Transfer Protocol (HTTP) that has been registered with the Internet Assigned Numbers Authority (IANA) following the "Registration Procedures for Message Header Fields" [RFC3864].
The purpose of TLDR is to allow for an automated process of file verification assuming a Trusted Linker. Provided the Trusted Linker can be truly trusted, the method is sound.
The most important consideration is whether or not the the Trusted Linker is actually trustworthy. If it is not, then TLDR offers no benefit. As a result, user agents that implement TLDR SHOULD make it clear to the user which https:// URL is being trusted.
This is necessary because a string of redirects (using HTTP, JavaScript, or any other method) could trick the user into confusing the actual Trusted Linker for a different site:
https://trusted.example.com/files/file.tar.gz |=== redirects in some way to ===> http://hacked.example.org/files/file.tar.gz |=== which then redirects to ===> https://evil.example.net/tldr/file.tar.gz |=== which redirects using TLDR to ===> http://hacked.example.org/filez/file.tar.gz (which is malware and downloads with TLDR)
In the example, without information to the contrary, the user may incorrectly assume that the Trusted Linker is trusted.example.com but it is actually evil.example.net
As stated in Section 3, TLDR only provides detection of modification by a Man in the Middle (MitM) if the checksum headers are delivered via HTTPS. If they are instead delivered by plain HTTP, they can be modified in transit by the MitM such that the checksums verify a different file of the MitM's choosing which they can then deliver to the user agent.
Although TLDR can help to detect when there is an integrity problem with a file download, it offers no means to retrieve a verified file should this situation arise.
How can a Trusted Linker obtain the file in a secure way such that they can be sure of its integrity before calculating the checksum? This is somewhat outside of the scope of this document but a few options include:
| [RFC-2119] | Bradner, S., "RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. |
| [RFC-2616] | Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "RFC 2616 - Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999. |
| [RFC-5246] | Dierks, T. and E. Rescorla, "RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. |
| [RFC-1321] | Rivest, R., "RFC 1321 - The MD5 Message-Digest Algorithm", RFC 1321, April 1992. |
| [RFC-3174] | Eastlake 3rd, D. and P. Jones, "RFC 3174 - US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. |
| [RFC-6234] | Eastlake 3rd, D. and T. Hansen, "RFC 6234 - US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. |
| [TLDR-Demo] | Kennish, B., "Trusted Linker Download Redirection (TLDR)", September 2014. |