idnits 2.17.1 draft-bennish-http-tldr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 5, 2014) is 3491 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 421 == Missing Reference: 'BCP90' is mentioned on line 300, but not defined == Missing Reference: 'RFC3864' is mentioned on line 316, but not defined -- Looks like a reference, but probably isn't: '1' on line 419 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Downref: Normative reference to an Informational RFC: RFC 6234 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Kennish 3 Internet-Draft Bennish.net 4 Intended status: Standards Track October 5, 2014 5 Expires: April 8, 2015 7 Trusted Linker Download Redirection (TLDR) 8 draft-bennish-http-tldr-00 10 Abstract 12 This document describes an HTTP extension that allows user agents to 13 verify downloaded data. It provides a standardised way for an HTTPS 14 URL (assumed trustworthy) to redirect to a non-HTTPS URL and give the 15 user agent extra information about the resulting output (e.g. a 16 downloaded file.) Once that is retrieved, it can check whether or 17 not the data has been modified since the trustworthy site checked it 18 (e.g. altered during transit or as a result of the destination site 19 having been compromised.) 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 8, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 Transport Layer Security (TLS/SSL) [RFC-5246] can add an often much 56 needed level of security to the Hypertext Transfer Protocol (HTTP) 57 [RFC-2616] (a combination normally referred to as HTTPS) but the 58 encryption algorithms are often too much of a strain for busy public 59 file download servers, especially when arguably the data stream does 60 not really need to be encrypted (the files are publicly accessible 61 anyway). 63 As a result, servers providing public file downloads, even 64 potentially dangerous file types such as those with executable code, 65 scripts, etc., often do not deliver the files using HTTPS. However, 66 this makes the downloads vulnerable to Man-in-the-Middle (MitM) 67 attacks; an attacker could change the data during transit to serve 68 the client with malware. 70 Trusted Linker Download Redirection (TLDR) describes a process by 71 which an (assumed trustworthy) HTTPS URL can redirect to a non-HTTPS 72 download URL and give the user agent extra information about the file 73 so that, once downloaded, the agent can check whether the file is the 74 same one that the trustworthy site verified. 76 1.1. Conventions and Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC-2119] 82 Trusted Linker The URL that provides the TLDR HTTP headers as it 83 redirects the user agent to a new URL (using the "Location:" 84 header). 86 The Link The URL that the trusted linker redirects to. Will be 87 identical to 'Final Destination' unless the Link redirects 88 elsewhere. 90 Final Destination The final URL (not necessarily using HTTP) that 91 provides the file data (may be identical to "The link") 93 2. Appropriate HTTP status codes 95 The TLDR headers SHOULD only be sent by the Trusted Link web server 96 with responses that use one of the following HTTP status codes: 98 o 302 "Found" 100 o 303 "See Other" 102 o 307 "Temporary Redirect" 104 Note that the permanent redirects (such as 301 "Moved Permanently" 105 and 308 "Permanent Redirect") are not included in the list. These 106 status codes instruct user agents to send all future requests to the 107 URL provided in the "Location" header, thereby bypassing the Trusted 108 Linker completely. It seems nonsensical to provide a TLDR service 109 for the user agent's first request only! 111 3. Redirection with plain HTTP 113 Ideally, servers implementing TLDR should do so over the HTTPS 114 protocol and not plain HTTP. If the headers are delivered without 115 the safety that TLS/SSL provides, TLDR cannot detect Man in the 116 Middle (MitM) attacks. 118 However, it does provides a bit of extra protection if used over 119 plain HTTP assuming no MitM. For example, if the Final Destination 120 server becomes compromised or for any other reason starts providing a 121 different file to the one that it was before, the checksum will not 122 match and this will be detected. 124 4. Checksum-related headers 126 These HTTP response headers are all OPTIONAL but a web server must 127 provide at least one to be a Trusted Linker. It should provide as 128 many of them as possible in order to give user agents the biggest 129 choice. To avoid ambiguity, a web server MUST NOT return more than 130 one TLDR header with the same name. 132 When more than one checksum is provided by the server, it is not 133 recommended for a user agent to use more that one of the checksums 134 provided. It should select one; preferably the checksum function 135 considered most secure at the time. The method by which the user 136 agent selects a hash function MAY be user configurable. 138 All checksums are calculated on the complete file contents. If the 139 file is delivered to the client using any kind of transfer encoding 140 (such as HTTP gzip, chunked, etc.), the checksums MUST be calculated 141 on the decoded data. Any kind of transfer mechanism that results in 142 ambiguous output data (such as "ASCII mode" FTP) is not supported. 144 The examples given below each show the server replying with a 145 different value for the HTTP status code. This is just to illustrate 146 the different codes that can use TLDR and bears no relationship to 147 the checksum hash function used. 149 While the examples with the longer header values are shown split to 150 multiple lines, this is to aid the readability of this document and 151 it is recommended that the actual header values are kept on a single 152 line. 154 4.1. Location-Checksum-MD5 156 Location-Checksum-MD5 = "Location-Checksum-MD5: " md5-checksum 158 md5-checksum should be a string giving the expected 128-bit MD5 159 message digest for the resulting downloaded file (see [RFC-1321]). 161 4.1.1. Example 163 HTTP/1.0 302 Moved Temporarily 164 Location: http://www.example.com/files/download.tar.gz 165 Location-Checksum-MD5: ccca8352847856cd4c2df77ce675de2b 167 4.2. Location-Checksum-SHA1 169 Location-Checksum-SHA1 = "Location-Checksum-SHA1: " sha1-checksum 171 sha1-checksum should be a string giving the expected 160bit SHA1 172 message digest for the resulting downloaded file (see [RFC-3174]). 174 4.2.1. Example 176 HTTP/1.1 302 Found 177 Location: http://www.example.com/files/download.tar.gz 178 Location-Checksum-SHA1: d98eaf66de93d9512958d6c7f5ed58d059dea53f 180 4.3. Location-Checksum-SHA256 182 Location-Checksum-SHA256 = "Location-Checksum-SHA256: " 183 sha256-checksum 185 sha256-checksum should be a string giving the expected 256bit SHA-256 186 message digest for the resulting downloaded file (see [RFC-6234]). 188 4.3.1. Example 190 HTTP/1.1 303 See Other 191 Location: http://www.example.com/files/download.tar.gz 192 Location-Checksum-SHA256: d9c30fccbfd25469b41c1e2c68b3b1a8f2a241e1808 193 07d6beb3bc63ddfef6ff2 195 4.4. Location-Checksum-SHA512 197 Location-Checksum-SHA512 = "Location-Checksum-SHA512: " 198 sha512-checksum 200 sha512-checksum should be a string giving the expected 512bit SHA-512 201 message digest for the resulting downloaded file (see [RFC-6234]). 203 4.4.1. Example 205 HTTP/1.1 307 Temporary Redirect 206 Location: http://www.example.com/files/download.tar.gz 207 Location-Checksum-SHA5126: a5555882da0419d98dd6b098e616aa66d7a5c13e54 208 9c2ab59dd7634ed07e379fafb4370925f65ff08d0cd50a19691acb6671a8d30b5298 209 0130dcc1bbfaf6a351 211 5. Appropriate user agent responses 213 5.1. On starting a TLDR download 215 The user agent MAY display some kind of notification to the user upon 216 starting a download using TLDR. However, it SHOULD NOT show any 217 notification unless the Trusted Linker used HTTPS (because it might 218 give the user a false sense of safety.) 220 5.2. On completing a TLDR download 222 Once the file has completely downloaded, the user agent calculates a 223 checksum using its choice of the provided message digest algorithms 224 and compares it to the one provided by the Trusted Linker. It then 225 takes appropriate action depending on the result: 227 5.2.1. When the checksums match 229 If the original TLDR checksum headers were sent using HTTPS, user 230 agents MAY notify the user that the downloaded file was as expected 231 according to the Trusted Linker. However, if they do, they SHOULD 232 clearly provide the user with enough information about the Trusted 233 Linker URL so that they can decide whether or not they do actually 234 trust it (e.g. the fully qualified domain name). See the Security 235 Considerations section for an explanation as to why this is 236 necessary. 238 If the original TLDR checksum headers were sent over plain HTTP, user 239 agents SHOULD NOT give any positive feedback to the user because of 240 the possibility of a Man in the Middle (MitM) attack. 242 5.2.2. When the checksums do not match 244 All the statements in this section apply even if the TLDR checksum 245 headers were sent over plain HTTP. Any checksum mismatch is a cause 246 for alarm. 248 If the checksums do not match, the user agent MUST give some kind of 249 feedback to warn the user that something is wrong. 251 The user agent SHOULD also remove or quarantine the downloaded file 252 to prevent it being used accidentally. 254 6. TLDR multiple times in a single request chain 256 It is possible for a Trusted Linker to redirect to a Link that 257 redirects again. There could be any number of redirections and any 258 of the hops along this redirect chain could also provide new TLDR 259 headers. If this happens, a user agent SHOULD simply ignore these 260 headers. The first hop in a chain of redirects that provides TLDR is 261 considered the most trust-worthy. 263 7. In practice 265 The author has created a prototype Add-on for the Mozilla Firefox web 266 browser which demonstrates TLDR in action. Links to download the 267 Add-on and some example download links that implement TLDR can be 268 found at a page on the author's website [TLDR-Demo]. 270 8. Possible future extension 272 TLDR could be extended in the future to take advantage of other types 273 of verification. Perhaps OpenPGP [1]-related HTTP response headers 274 could be used, possibly by providing one or more trusted public key 275 fingerprints along with the URL of a signature for the file. I hope 276 to explore this idea in future revisions of this document. 278 9. TL;DR 280 The author is aware of the existing acronym "TL;DR" meaning "Too 281 Long; Didn't Read" and feels that it is appropriate that this 282 proposed standard has the same acronym as it aptly describes the way 283 most people probably feel when they see instructions on how to 284 manually verify the integrity of their downloads such as these 285 instructions on httpd.apache.org. [2] The author would like to make 286 it clear that he is not criticising these instructions in any way but 287 instead pointing out that a manual verification process is quite 288 lengthy and tedious. 290 10. IANA Considerations 292 10.1. Header Field Registrations 294 [TO BE REMOVED: HTTP header fields should be registered within the 295 "Message Headers" registry maintained at 296 https://www.iana.org/assignments/message-headers/ ] 298 This document defines a number of HTTP header fields, so their 299 associated registry entries shall be added according to the permanent 300 registrations below (see [BCP90]): 302 +--------------------------+----------+----------+-------------+ 303 | Header Field Name | Protocol | Status | Reference | 304 +--------------------------+----------+----------+-------------+ 305 | Location-Checksum-MD5 | http | standard | Section 4.1 | 306 | Location-Checksum-SHA1 | http | standard | Section 4.2 | 307 | Location-Checksum-SHA256 | http | standard | Section 4.3 | 308 | Location-Checksum-SHA512 | http | standard | Section 4.4 | 309 +--------------------------+----------+----------+-------------+ 311 The change controller is: "IETF (iesg@ietf.org) - Internet 312 Engineering Task Force". This specification defines a number of 313 response header fields for the Hypertext Transfer Protocol (HTTP) 314 that has been registered with the Internet Assigned Numbers Authority 315 (IANA) following the "Registration Procedures for Message Header 316 Fields" [RFC3864]. 318 11. Security Considerations 320 The purpose of TLDR is to allow for an automated process of file 321 verification assuming a Trusted Linker. Provided the Trusted Linker 322 can be truly trusted, the method is sound. 324 11.1. Trusted Linker 326 The most important consideration is whether or not the the Trusted 327 Linker is actually trustworthy. If it is not, then TLDR offers no 328 benefit. As a result, user agents that implement TLDR SHOULD make it 329 clear to the user which https:// URL is being trusted. 331 This is necessary because a string of redirects (using HTTP, 332 JavaScript, or any other method) could trick the user into confusing 333 the actual Trusted Linker for a different site: 335 https://trusted.example.com/files/file.tar.gz 336 |=== redirects in some way to ===> 337 http://hacked.example.org/files/file.tar.gz 338 |=== which then redirects to ===> 339 https://evil.example.net/tldr/file.tar.gz 340 |=== which redirects using TLDR to ===> 341 http://hacked.example.org/filez/file.tar.gz 342 (which is malware and downloads with TLDR) 344 In the example, without information to the contrary, the user may 345 incorrectly assume that the Trusted Linker is trusted.example.com but 346 it is actually evil.example.net 348 11.2. Man in the Middle 350 As stated in Section 3, TLDR only provides detection of modification 351 by a Man in the Middle (MitM) if the checksum headers are delivered 352 via HTTPS. If they are instead delivered by plain HTTP, they can be 353 modified in transit by the MitM such that the checksums verify a 354 different file of the MitM's choosing which they can then deliver to 355 the user agent. 357 11.3. Limitations 359 Although TLDR can help to detect when there is an integrity problem 360 with a file download, it offers no means to retrieve a verified file 361 should this situation arise. 363 How can a Trusted Linker obtain the file in a secure way such that 364 they can be sure of its integrity before calculating the checksum? 365 This is somewhat outside of the scope of this document but a few 366 options include: 368 o The Trusted Linker may have downloaded the file using HTTPS 370 o The Trusted Linker may have verified the file using OpenPGP and an 371 established Web of Trust. 373 o The Trusted Linker and Final Destination servers may belong to the 374 same organisation, e.g. the Trusted Linker could be 375 https://trusted.example.com/tldr/software.tar.gz and the Final 376 Destination could be http://trusted.example.com/files/ 377 software.tar.gz 379 12. References 381 12.1. Normative References 383 [RFC-2119] 384 Bradner, S., "RFC 2119 - Key words for use in RFCs to 385 Indicate Requirement Levels", RFC 2119, March 1997. 387 [RFC-2616] 388 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 389 Masinter, L., Leach, P., and T. Berners-Lee, "RFC 2616 - 390 Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 391 1999. 393 [RFC-5246] 394 Dierks, T. and E. Rescorla, "RFC 5246 - The Transport 395 Layer Security (TLS) Protocol Version 1.2", RFC 5246, 396 August 2008. 398 [RFC-1321] 399 Rivest, R., "RFC 1321 - The MD5 Message-Digest Algorithm", 400 RFC 1321, April 1992. 402 [RFC-3174] 403 Eastlake 3rd, D. and P. Jones, "RFC 3174 - US Secure Hash 404 Algorithm 1 (SHA1)", RFC 3174, September 2001. 406 [RFC-6234] 407 Eastlake 3rd, D. and T. Hansen, "RFC 6234 - US Secure Hash 408 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, 409 May 2011. 411 12.2. Informative References 413 [TLDR-Demo] 414 Kennish, B., "Trusted Linker Download Redirection (TLDR)", 415 September 2014, . 417 12.3. URIs 419 [1] http://www.openpgp.org 421 [2] http://httpd.apache.org/download.cgi#verify 423 Author's Address 425 Ben A. Kennish 426 Bennish.net 428 Email: ben@kennish.net 429 URI: http://www.bennish.net/