Internet DRAFT - draft-bennish-http-tldr
draft-bennish-http-tldr
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
Abstract
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.)
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 April 8, 2015.
Copyright Notice
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
Kennish Expires April 8, 2015 [Page 1]
Internet-Draft Trusted Linker Download Redirection (TLDR) October 2014
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.
1. Introduction
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.
1.1. Conventions and Terminology
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]
Trusted Linker The URL that provides the TLDR HTTP headers as it
redirects the user agent to a new URL (using the "Location:"
header).
The Link The URL that the trusted linker redirects to. Will be
identical to 'Final Destination' unless the Link redirects
elsewhere.
Final Destination The final URL (not necessarily using HTTP) that
provides the file data (may be identical to "The link")
Kennish Expires April 8, 2015 [Page 2]
Internet-Draft Trusted Linker Download Redirection (TLDR) October 2014
2. Appropriate HTTP status codes
The TLDR headers SHOULD only be sent by the Trusted Link web server
with responses that use one of the following HTTP status codes:
o 302 "Found"
o 303 "See Other"
o 307 "Temporary Redirect"
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!
3. Redirection with plain HTTP
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.
4. Checksum-related headers
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
Kennish Expires April 8, 2015 [Page 3]
Internet-Draft Trusted Linker Download Redirection (TLDR) October 2014
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.
4.1. Location-Checksum-MD5
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]).
4.1.1. Example
HTTP/1.0 302 Moved Temporarily
Location: http://www.example.com/files/download.tar.gz
Location-Checksum-MD5: ccca8352847856cd4c2df77ce675de2b
4.2. Location-Checksum-SHA1
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]).
4.2.1. Example
HTTP/1.1 302 Found
Location: http://www.example.com/files/download.tar.gz
Location-Checksum-SHA1: d98eaf66de93d9512958d6c7f5ed58d059dea53f
4.3. Location-Checksum-SHA256
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]).
Kennish Expires April 8, 2015 [Page 4]
Internet-Draft Trusted Linker Download Redirection (TLDR) October 2014
4.3.1. Example
HTTP/1.1 303 See Other
Location: http://www.example.com/files/download.tar.gz
Location-Checksum-SHA256: d9c30fccbfd25469b41c1e2c68b3b1a8f2a241e1808
07d6beb3bc63ddfef6ff2
4.4. Location-Checksum-SHA512
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]).
4.4.1. Example
HTTP/1.1 307 Temporary Redirect
Location: http://www.example.com/files/download.tar.gz
Location-Checksum-SHA5126: a5555882da0419d98dd6b098e616aa66d7a5c13e54
9c2ab59dd7634ed07e379fafb4370925f65ff08d0cd50a19691acb6671a8d30b5298
0130dcc1bbfaf6a351
5. Appropriate user agent responses
5.1. On starting a TLDR download
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.)
5.2. On completing a TLDR download
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:
5.2.1. When the checksums match
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
Kennish Expires April 8, 2015 [Page 5]
Internet-Draft Trusted Linker Download Redirection (TLDR) October 2014
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.
5.2.2. When the checksums do not match
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.
6. TLDR multiple times in a single request chain
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.
7. In practice
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].
8. Possible future extension
TLDR could be extended in the future to take advantage of other types
of verification. Perhaps OpenPGP [1]-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.
9. TL;DR
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
Kennish Expires April 8, 2015 [Page 6]
Internet-Draft Trusted Linker Download Redirection (TLDR) October 2014
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. [2] 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.
10. IANA Considerations
10.1. Header Field Registrations
[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].
11. Security Considerations
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.
11.1. Trusted Linker
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.
Kennish Expires April 8, 2015 [Page 7]
Internet-Draft Trusted Linker Download Redirection (TLDR) October 2014
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
11.2. Man in the Middle
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.
11.3. Limitations
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:
o The Trusted Linker may have downloaded the file using HTTPS
o The Trusted Linker may have verified the file using OpenPGP and an
established Web of Trust.
o The Trusted Linker and Final Destination servers may belong to the
same organisation, e.g. the Trusted Linker could be
https://trusted.example.com/tldr/software.tar.gz and the Final
Destination could be http://trusted.example.com/files/
software.tar.gz
Kennish Expires April 8, 2015 [Page 8]
Internet-Draft Trusted Linker Download Redirection (TLDR) October 2014
12. References
12.1. Normative References
[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.
12.2. Informative References
[TLDR-Demo]
Kennish, B., "Trusted Linker Download Redirection (TLDR)",
September 2014, <https://www.bennish.net/tldr/>.
12.3. URIs
[1] http://www.openpgp.org
[2] http://httpd.apache.org/download.cgi#verify
Kennish Expires April 8, 2015 [Page 9]
Internet-Draft Trusted Linker Download Redirection (TLDR) October 2014
Author's Address
Ben A. Kennish
Bennish.net
Email: ben@kennish.net
URI: http://www.bennish.net/
Kennish Expires April 8, 2015 [Page 10]
