Network Working Group                                         B. Kennish
Intended status: Standards Track                           April 8, 2015
Expires: October 10, 2015

               Trusted Linker Download Redirection (TLDR)


   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

   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 October 10, 2015.

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
   ( 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 October 10, 2015                [Page 1]

Internet-Draft Trusted Linker Download Redirection (TLDR)     April 2015

   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-7230] (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

   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",
   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:"

   The Link  The URL that the trusted linker redirects to.  Will be
      identical to 'Final Destination' unless the Link redirects

   Final Destination  The final URL (not necessarily using HTTP) that
      provides the file data (may be identical to "The link")

Kennish                 Expires October 10, 2015                [Page 2]

Internet-Draft Trusted Linker Download Redirection (TLDR)     April 2015

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 than 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 October 10, 2015                [Page 3]

Internet-Draft Trusted Linker Download Redirection (TLDR)     April 2015

   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

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-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-Checksum-SHA1: d98eaf66de93d9512958d6c7f5ed58d059dea53f

4.3.  Location-Checksum-SHA256

   Location-Checksum-SHA256 = "Location-Checksum-SHA256: "

   sha256-checksum should be a string giving the expected 256bit SHA-256
   message digest for the resulting downloaded file (see [RFC-6234]).

Kennish                 Expires October 10, 2015                [Page 4]

Internet-Draft Trusted Linker Download Redirection (TLDR)     April 2015

4.3.1.  Example

   HTTP/1.1 303 See Other
   Location-Checksum-SHA256: d9c30fccbfd25469b41c1e2c68b3b1a8f2a241e1808

4.4.  Location-Checksum-SHA512

   Location-Checksum-SHA512 = "Location-Checksum-SHA512: "

   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-Checksum-SHA5126: a5555882da0419d98dd6b098e616aa66d7a5c13e54

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 October 10, 2015                [Page 5]

Internet-Draft Trusted Linker Download Redirection (TLDR)     April 2015

   Considerations section for an explanation as to why this is

   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 October 10, 2015                [Page 6]

Internet-Draft Trusted Linker Download Redirection (TLDR)     April 2015

   most people probably feel when they see instructions on how to
   manually verify the integrity of their downloads such as these
   instructions on [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, and therefore often skipped completely.

10.  IANA Considerations

10.1.  Header Field Registrations

   [TO BE REMOVED: HTTP header fields should be registered within the
   "Message Headers" registry maintained at ]

   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 ( - 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 October 10, 2015                [Page 7]

Internet-Draft Trusted Linker Download Redirection (TLDR)     April 2015

   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:
      |=== redirects in some way to ===>
      |=== which then redirects to ===>
      |=== which redirects using TLDR to ===>
      (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 but
   it is actually

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 and the Final
      Destination could be

Kennish                 Expires October 10, 2015                [Page 8]

Internet-Draft Trusted Linker Download Redirection (TLDR)     April 2015

12.  References

12.1.  Normative References

              Bradner, S., "RFC 2119 - Key words for use in RFCs to
              Indicate Requirement Levels", RFC 2119, March 1997.

              Fielding, R. and J. Reschke, "RFC 7230 - Hypertext
              Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, June 2014.

              Dierks, T. and E. Rescorla, "RFC 5246 - The Transport
              Layer Security (TLS) Protocol Version 1.2", RFC 5246,
              August 2008.

12.2.  Informative References

              Rivest, R., "RFC 1321 - The MD5 Message-Digest Algorithm",
              RFC 1321, April 1992.

              Eastlake 3rd, D. and P. Jones, "RFC 3174 - US Secure Hash
              Algorithm 1 (SHA1)", RFC 3174, September 2001.

              Eastlake 3rd, D. and T. Hansen, "RFC 6234 - US Secure Hash
              Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              May 2011.

              Kennish, B., "Trusted Linker Download Redirection (TLDR)",
              September 2014, <>.

12.3.  URIs



Author's Address

Kennish                 Expires October 10, 2015                [Page 9]

Internet-Draft Trusted Linker Download Redirection (TLDR)     April 2015

   Ben A. Kennish


Kennish                 Expires October 10, 2015               [Page 10]