idnits 2.17.1 draft-ietf-httpbis-digest-headers-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document obsoletes RFC3230, but the header doesn't have an 'Obsoletes:' line to match this. 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 (July 04, 2019) is 1758 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: '1' on line 914 -- Looks like a reference, but probably isn't: '2' on line 916 -- Looks like a reference, but probably isn't: '3' on line 918 -- Looks like a reference, but probably isn't: '4' on line 920 -- Looks like a reference, but probably isn't: '5' on line 922 -- Looks like a reference, but probably isn't: '6' on line 924 -- Looks like a reference, but probably isn't: '7' on line 926 -- Looks like a reference, but probably isn't: '8' on line 928 -- Looks like a reference, but probably isn't: '9' on line 930 -- Possible downref: Non-RFC (?) normative reference: ref. 'CMU-836068' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'IACR-2019-459' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST800-32' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 3230 (Obsoleted by RFC 9530) ** Downref: Normative reference to an Informational RFC: RFC 5843 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7233 (Obsoleted by RFC 9110) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNIX' -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP R. Polli 3 Internet-Draft Team Digitale, Italian Government 4 Intended status: Standards Track L. Pardue 5 Expires: January 5, 2020 Cloudflare 6 July 04, 2019 8 Resource Digests for HTTP 9 draft-ietf-httpbis-digest-headers-00 11 Abstract 13 This document defines the Digest and Want-Digest header fields for 14 HTTP, thus allowing client and server to negotiate an integrity 15 checksum of the exchanged resource representation data. 17 This document obsoletes RFC 3230. It replaces the term "instance" 18 with "representation", which makes it consistent with the HTTP 19 Semantic and Context defined in RFC 7231. 21 Note to Readers 23 _RFC EDITOR: please remove this section before publication_ 25 Discussion of this draft takes place on the HTTP working group 26 mailing list (ietf-http-wg@w3.org), which is archived at 27 https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. 29 The source code and issues list for this draft can be found at 30 https://github.com/httpwg/http-extensions [2]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 5, 2020. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Brief history of integrity headers . . . . . . . . . . . 4 68 1.2. This proposal . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.4. Notational Conventions . . . . . . . . . . . . . . . . . 5 71 2. Resource representation and representation-data . . . . . . . 5 72 3. Digest Algorithm values . . . . . . . . . . . . . . . . . . . 7 73 3.1. Representation digest . . . . . . . . . . . . . . . . . . 9 74 3.1.1. digest-algorithm encoding examples . . . . . . . . . 9 75 4. Header Specifications . . . . . . . . . . . . . . . . . . . . 10 76 4.1. Want-Digest . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.2. Digest . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5. Deprecate Negotiation of Content-MD5 . . . . . . . . . . . . 11 79 6. Broken cryptographic algorithms are NOT RECOMMENDED . . . . . 11 80 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 7.1. Unsolicited Digest response . . . . . . . . . . . . . . . 11 82 7.1.1. Representation data is fully contained in the payload 11 83 7.1.2. Representation data is not contained in the payload . 12 84 7.1.3. Representation data is partially contained in the 85 payload i.e. range request . . . . . . . . . . . . . 12 86 7.1.4. Digest in both Request and Response. Returned value 87 depends on representation metadata . . . . . . . . . 13 88 7.2. Want-Digest solicited digest responses . . . . . . . . . 13 89 7.2.1. Client request data is fully contained in the payload 13 90 7.2.2. A client requests an unsupported Digest, the server 91 MAY reply with an unsupported digest . . . . . . . . 14 92 7.2.3. A client requests an unsupported Digest, the server 93 MAY reply with a 400 . . . . . . . . . . . . . . . . 14 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 95 8.1. Digest does not protect the full HTTP message . . . . . . 14 96 8.2. Broken cryptographic algorithms . . . . . . . . . . . . . 15 97 8.3. Digest for end-to-end integrity . . . . . . . . . . . . . 15 98 8.4. Usage in signatures . . . . . . . . . . . . . . . . . . . 15 99 8.5. Message Truncation . . . . . . . . . . . . . . . . . . . 16 100 8.6. Algorithm Agility . . . . . . . . . . . . . . . . . . . . 16 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 102 9.1. Establish the HTTP Digest Algorithm Values . . . . . . . 16 103 9.2. The "status" field in the HTTP Digest Algorithm Values . 16 104 9.3. Obsolete "MD5" Digest Algorithm . . . . . . . . . . . . . 16 105 9.4. Obsolete "SHA" Digest Algorithm . . . . . . . . . . . . . 16 106 9.5. The "ID-SHA-256" Digest Algorithm . . . . . . . . . . . . 17 107 9.6. The "ID-SHA-512" Digest Algorithm . . . . . . . . . . . . 17 108 9.7. Changes compared to RFC5843 . . . . . . . . . . . . . . . 17 109 9.8. Want-Digest Header Field Registration . . . . . . . . . . 17 110 9.9. Digest Header Field Registration . . . . . . . . . . . . 18 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 112 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 113 10.2. Informative References . . . . . . . . . . . . . . . . . 20 114 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 115 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 116 Appendix B. FAQ . . . . . . . . . . . . . . . . . . . . . . . . 21 117 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 120 1. Introduction 122 Integrity protection for HTTP content is multi layered and is usually 123 achieved across the protocol stack: TCP checksums and TLS [RFC2818] 124 record to name but some. 126 The HTTP protocol does not provide means to protect the various 127 message parts. Besides, it might be desirable to add additional 128 guarantees to the ones provided by the transport layer (eg. HTTPS). 129 This may be in order to: 131 o detect programming errors and corruption of stored data; 133 o address the need for the representation-data to remain unmodified 134 throughout multiple hops; 136 o implement signature mechanisms that cover the desired parts of an 137 HTTP exchange; 139 o provide additional protection against failures or attack (see 140 [SRI]). 142 1.1. Brief history of integrity headers 144 The Content-MD5 header field was originally introduced to provide 145 integrity, but HTTP/1.1 [RFC7231] in appendix-B obsoleted it: 147 The Content-MD5 header field has been removed because it was 148 inconsistently implemented with respect to partial responses. 150 [RFC3230] provided a more flexible solution introducing the concept 151 of "instance", and the headers "Digest" and "Want-Digest". 153 1.2. This proposal 155 The concept of "selected representation" defined in [RFC7231] made 156 [RFC3230] definitions inconsistent with the current standard. A 157 refresh was then required. 159 This document updates the "Digest" and "Want-Digest" header field 160 definitions to align with [RFC7231] concepts. 162 This approach can be easily adapted to use-cases where the 163 transferred data does require some sort of manipulation to be 164 considered a representation or conveys a partial representation of a 165 resource (eg. Range Requests [RFC7233]). 167 Changes are semantically compatible with existing implementations and 168 better cover both the request and response cases. 170 The value of "Digest" is calculated on selected representation, which 171 is tied to the value contained in any "Content-Encoding" or "Content- 172 Type" header fields. Therefore, a given resource may have multiple 173 different digest values. 175 To allow both parties to exchange a Digest of a representation with 176 no content codings [3] two more algorithms are added ("ID-SHA-256" 177 and "ID-SHA-512"). 179 1.3. Goals 181 The goals of this proposal are: 183 1. Digest coverage for either the resource's "representation data" 184 or "selected representation data" communicated via HTTP. 186 2. Support for multiple digest algorithms. 188 3. Negotiation of the use of digests. 190 The goals do not include: 192 HTTP Message integrity: The digest mechanism described here does not 193 cover the full HTTP message nor its semantic, as representation 194 metadata are not included in the checksum. 196 Header integrity: The digest mechanisms described here cover only 197 representation and selected representation data, and do not 198 protect the integrity of associated representation metadata 199 headers or other message headers. 201 Authentication: The digest mechanisms described here are not meant 202 to support authentication of the source of a digest or of a 203 message or anything else. These mechanisms, therefore, are not a 204 sufficient defense against many kinds of malicious attacks. 206 Privacy: Digest mechanisms do not provide message privacy. 208 Authorization: The digest mechanisms described here are not meant to 209 support authorization or other kinds of access controls. 211 1.4. Notational Conventions 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 215 "OPTIONAL" in this document are to be interpreted as described in BCP 216 14 ([RFC2119] and [RFC8174]) when, and only when, they appear in all 217 capitals, as shown here. 219 This document uses the Augmented BNF defined in [RFC5234] and updated 220 by [RFC7405] along with the "#rule" extension defined in Section 7 of 221 [RFC7230]. 223 The definitions "representation", "selected representation", 224 "representation data", "representation metadata" and "payload body" 225 in this document are to be interpreted as described in [RFC7230] and 226 [RFC7231]. 228 2. Resource representation and representation-data 230 To avoid inconsistencies, an integrity mechanism for HTTP messages 231 should decouple the checksum calculation: 233 o from the payload body - which may be altered by mechanism like 234 Range Requests [RFC7233] or the method (eg. HEAD); 236 o and from the message body - which depends on "Transfer-Encoding" 237 and whatever tranformations the intermediaries may apply. 239 The following examples show how representation metadata, payload 240 tranformations and method impacts on the message and payload body. 242 Here is a gzip-compressed json object 244 Request: 246 PUT /entries/1234 HTTP/1.1 247 Content-Type: application/json 248 Content-Encoding: gzip 250 H4sIAItWyFwC/6tWSlSyUlAypANQqgUAREcqfG0AAAA= 252 Now the same payload body conveys a malformed json object. 254 Request: 256 PUT /entries/1234 HTTP/1.1 257 Content-Type: application/json 259 H4sIAItWyFwC/6tWSlSyUlAypANQqgUAREcqfG0AAAA= 261 A Range-Request alters the payload body, conveying a partial 262 representation. 264 Request: 266 GET /entries/1234 HTTP/1.1 267 Range: bytes=1-7 269 Response: 271 HTTP/1.1 206 Partial Content 272 Content-Encoding: gzip 273 Content-Type: application/json 274 Content-Range: bytes=1-7 276 iwgAla3RXA== 278 Now the method too alters the payload body. 280 Request: 282 HEAD /entries/1234 HTTP/1.1 283 Accept: application/json 284 Accept-Encoding: gzip 286 Response: 288 HTTP/1.1 200 OK 289 Content-Type: application/json 290 Content-Encoding: gzip 292 3. Digest Algorithm values 294 Digest algorithm values are used to indicate a specific digest 295 computation. For some algorithms, one or more parameters may be 296 supplied. 298 digest-algorithm = token 300 The BNF for "parameter" is as is used in [RFC7230]. All digest- 301 algorithm values are case-insensitive. 303 The Internet Assigned Numbers Authority (IANA) acts as a registry for 304 digest-algorithm values. The registry contains the following tokens. 306 SHA-256: 308 * Description: The SHA-256 algorithm [FIPS180-3]. The output of 309 this algorithm is encoded using the base64 encoding [RFC4648]. 311 * Reference: [FIPS180-3], [RFC4648], this document. 313 * Status: standard 315 SHA-512: 317 * Description: The SHA-512 algorithm [FIPS180-3]. The output of 318 this algorithm is encoded using the base64 encoding [RFC4648]. 320 * Reference: [FIPS180-3], [RFC4648], this document. 322 * Status: standard 324 MD5: 326 * Description: The MD5 algorithm, as specified in [RFC1321]. The 327 output of this algorithm is encoded using the base64 encoding 328 [RFC4648]. The MD5 algorithm is NOT RECOMMENDED as it's now 329 vulnerable to collision attacks [CMU-836068]. 331 * Reference: [RFC1321], [RFC4648], this document. 333 * Status: obsoleted 335 SHA: 337 * Description: The SHA-1 algorithm [FIPS180-1]. The output of 338 this algorithm is encoded using the base64 encoding [RFC4648]. 339 The SHA algorithm is NOT RECOMMENDED as it's now vulnerable to 340 collision attacks [IACR-2019-459]. 342 * Reference: [FIPS180-3], [RFC4648], this document. 344 * Status: obsoleted 346 UNIXsum: 348 * Description: The algorithm computed by the UNIX "sum" command, 349 as defined by the Single UNIX Specification, Version 2 [UNIX]. 350 The output of this algorithm is an ASCII decimal-digit string 351 representing the 16-bit checksum, which is the first word of 352 the output of the UNIX "sum" command. 354 * Reference: [UNIX], this document. 356 * Status: standard 358 UNIXcksum: 360 * Description: The algorithm computed by the UNIX "cksum" 361 command, as defined by the Single UNIX Specification, Version 2 362 [UNIX]. The output of this algorithm is an ASCII digit string 363 representing the 32-bit CRC, which is the first word of the 364 output of the UNIX "cksum" command. 366 * Reference: [UNIX], this document. 368 * Status: standard 370 To allow sender and recipient to provide a checksum which is 371 independent from "Content-Encoding", the following additional 372 algorithms are defined: 374 ID-SHA-512: 376 * Description: The sha-512 digest of the representation-data of 377 the resource when no content coding is applied (eg. "Content- 378 Encoding: identity") 380 * Reference: [FIPS180-3], [RFC4648], this document. 382 * Status: standard 384 ID-SHA-256: 386 * Description: The sha-256 digest of the representation-data of 387 the resource when no content coding is applied (eg. "Content- 388 Encoding: identity") 390 * Reference: [FIPS180-3], [RFC4648], this document. 392 * Status: standard 394 If other digest-algorithm values are defined, the associated encoding 395 MUST either be represented as a quoted string, or MUST NOT include 396 ";" or "," in the character sets used for the encoding. 398 3.1. Representation digest 400 A representation digest is the value of the output of a digest 401 algorithm, together with an indication of the algorithm used (and any 402 parameters). 404 representation-data-digest = digest-algorithm "=" 405 407 As explained in Section 2 the digest is computed on the entire 408 selected "representation data" of the resource defined in [RFC7231]: 410 representation-data := Content-Encoding( Content-Type( bits ) ) 412 The encoded digest output uses the encoding format defined for the 413 specific digest-algorithm. 415 3.1.1. digest-algorithm encoding examples 417 The "sha-256" digest-algorithm uses base64 encoding. Note that 418 digest-algoritm values are case insensitive. 420 sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= 421 The "UNIXsum" digest-algorithm uses ASCII string of decimal digits. 423 UNIXsum=30637 425 4. Header Specifications 427 The following headers are defined 429 4.1. Want-Digest 431 The Want-Digest message header field indicates the sender's desire to 432 receive a representation digest on messages associated with the 433 Request- URI and representation metadata. 435 Want-Digest = "Want-Digest" ":" OWS 1#want-digest-value 436 want-digest-value = digest-algorithm [ ";" "q" "=" qvalue] 437 qvalue = ( "0" [ "." 0*1DIGIT ] ) / ( "1" [ "." 0*1( "0" ) ] ) 439 If a digest-algorithm is not accompanied by a qvalue, it is treated 440 as if its associated qvalue were 1.0. 442 The sender is willing to accept a digest-algorithm if and only if it 443 is listed in a Want-Digest header field of a message, and its qvalue 444 is non-zero. 446 If multiple acceptable digest-algorithm values are given, the 447 sender's preferred digest-algorithm is the one (or ones) with the 448 highest qvalue. 450 Examples: 452 Want-Digest: sha-256 453 Want-Digest: SHA-512;q=0.3, sha-256;q=1, md5;q=0 455 4.2. Digest 457 The Digest header field provides a digest of the representation data 459 Digest = "Digest" ":" OWS 1#representation-data-digest 461 "Representation data" might be: 463 o fully contained in the message body, 465 o partially-contained in the message body, 467 o or not at all contained in the message body. 469 The resource is specified by the effective Request-URI and any cache- 470 validator contained in the message. 472 For example, in a response to a HEAD request, the digest is 473 calculated using the representation data that would have been 474 enclosed in the payload body if the same request had been a GET. 476 Digest can be used in requests too. Returned value depends on the 477 representation metadata headers. 479 A Digest header field MAY contain multiple representation-data-digest 480 values. This could be useful for responses expected to reside in 481 caches shared by users with different browsers, for example. 483 A recipient MAY ignore any or all of the representation-data-digests 484 in a Digest header field. This allows the recipient to chose which 485 digest-algorithm(s) to use for validation instead of verifying every 486 received representation-data-digest. 488 A sender MAY send a representation-data-digest using a digest- 489 algorithm without knowing whether the recipient supports the digest- 490 algorithm, or even knowing that the recipient will ignore it. 492 ... 494 5. Deprecate Negotiation of Content-MD5 496 This RFC deprecates the negotiation of Content-MD5 as this header has 497 been obsoleted by [RFC7231] 499 6. Broken cryptographic algorithms are NOT RECOMMENDED 501 The MD5 algorithm is NOT RECOMMENDED as it's now vulnerable to 502 collision attacks [CMU-836068]. 504 The SHA algorithm is NOT RECOMMENDED as it's now vulnerable to 505 collision attacks [IACR-2019-459]. 507 7. Examples 509 7.1. Unsolicited Digest response 511 7.1.1. Representation data is fully contained in the payload 512 Request: 514 GET /items/123 516 Response: 518 HTTP/1.1 200 Ok 519 Content-Type: application/json 520 Content-Encoding: identity 521 Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= 523 {"hello": "world"} 525 7.1.2. Representation data is not contained in the payload 527 Request: 529 HEAD /items/123 531 Response: 533 HTTP/1.1 200 Ok 534 Content-Type: application/json 535 Content-Encoding: identity 536 Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= 538 7.1.3. Representation data is partially contained in the payload i.e. 539 range request 541 Request: 543 GET /items/123 544 Range: bytes=1-7 546 Response: 548 HTTP/1.1 206 Partial Content 549 Content-Type: application/json 550 Content-Encoding: identity 551 Content-Range: bytes 1-7/18 552 Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= 554 "hello" 556 7.1.4. Digest in both Request and Response. Returned value depends on 557 representation metadata 559 Digest can be used in requests too. Returned value depends on the 560 representation metadata headers. 562 Request: 564 PUT /items/123 565 Content-Type: application/json 566 Content-Encoding: identity 567 Accept-Encoding: br 568 Digest: sha-256=4REjxQ4yrqUVicfSKYNO/cF9zNj5ANbzgDZt3/h3Qxo= 570 {"hello": "world"} 572 Response: 574 Content-Type: application/json 575 Content-Encoding: br 576 Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= 578 iwiAeyJoZWxsbyI6ICJ3b3JsZCJ9Aw== 580 7.2. Want-Digest solicited digest responses 582 7.2.1. Client request data is fully contained in the payload 584 The client requests a digest, preferring sha. The server is free to 585 reply with sha-256 anyway. 587 Request: 589 GET /items/123 590 Want-Digest: sha-256;q=0.3, sha;q=1 592 Response: 594 HTTP/1.1 200 Ok 595 Content-Type: application/json 596 Content-Encoding: identity 597 Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= 599 {"hello": "world"} 601 7.2.2. A client requests an unsupported Digest, the server MAY reply 602 with an unsupported digest 604 The client requests a sha digest only. The server is currently free 605 to reply with a Digest containing an unsupported algorithm 607 Request: 609 GET /items/123 610 Want-Digest: sha;q=1 612 Response: 614 HTTP/1.1 200 Ok 615 Content-Type: application/json 616 Content-Encoding: identity 617 Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= 619 {"hello": "world"} 621 7.2.3. A client requests an unsupported Digest, the server MAY reply 622 with a 400 624 The client requests a sha Digest, the server advises for sha-256 and 625 sha-512 627 Request: 629 GET /items/123 630 Want-Digest: sha;q=1 632 Response: 634 HTTP/1.1 400 Bad Request 635 Want-Digest: sha-256, sha-512 637 ... 639 8. Security Considerations 641 8.1. Digest does not protect the full HTTP message 643 This document specifies a data integrity mechanism that protects HTTP 644 "representation data", but not HTTP "representation metadata" 645 headers, from certain kinds of accidental corruption. 647 While it is not intended as general protection against malicious 648 tampering with HTTP messages, this goal can be achieved using 649 "Digest" together with a transport-layer security mechanism and 650 digital signatures. 652 8.2. Broken cryptographic algorithms 654 Cryptogrphic alorithms are intended to provide a proof of integrity 655 suited towards cryptographic constructions such as signatures. 657 However, these rely on collision-resistance for their security proofs 658 [CMU-836068]. The MD5 and SHA-1 algorithms are vulnerable to 659 collisions attacks and they are NOT RECOMMENDED. 661 8.3. Digest for end-to-end integrity 663 "Digest" alone does not provide end-to-end integrity of HTTP messages 664 over multiple hops, as it just covers the "representation data" and 665 not the "representation metadata". 667 Besides, it allows to protect "representation data" from buggy 668 manipulation, buggy compression, etc. 670 Moreover identity digest algorithms (eg. ID-SHA-256 and ID-SHA-512) 671 allow piecing together a resource from different sources (e.g. 672 different servers that perhaps apply different content codings) 673 enabling the user-agent to detect that the application-layer tasks 674 completed properly, before handing off to say the HTML parser, video 675 player etc. 677 Even a simple mechanism for end-to-end validation is thus valuable. 679 8.4. Usage in signatures 681 Digital signatures are widely used together with checksums to provide 682 the certain identification of the origin of a message [NIST800-32]. 684 It's important to note that, being the "Digest" header an hash of a 685 resource representation, signing only the "Digest" header, without 686 all the "representation metatada" (eg. the values of "Content-Type" 687 and "Content-Encoding") may expose the communication to tampering. 689 "Digest" SHOULD always be used over a connection which provides 690 integrity at transport layer that protects HTTP headers. 692 A "Digest" header using NOT RECOMMENDED digest-algorithms SHOULD NOT 693 be used in signatures. 695 8.5. Message Truncation 697 ... 699 8.6. Algorithm Agility 701 ... 703 9. IANA Considerations 705 9.1. Establish the HTTP Digest Algorithm Values 707 This memo sets this spec to be the establishing document for the HTTP 708 Digest Algorithm Values [4] 710 9.2. The "status" field in the HTTP Digest Algorithm Values 712 This memo adds the field "Status" to the HTTP Digest Algorithm Values 713 [5] registry. The allowed values for the "Status" fields are 714 described below. 716 Status Specify "standard", "experimental", "historic", "obsoleted", 717 or "deprecated" according to the type and status of the primary 718 document in which the algorithm is defined. 720 9.3. Obsolete "MD5" Digest Algorithm 722 This memo updates the "MD5" digest algorithm in the HTTP Digest 723 Algorithm Values [6] registry: 725 o Digest Algorithm: MD5 727 o Description: As specified in Section 3. 729 o Status: As specified in Section 3. 731 9.4. Obsolete "SHA" Digest Algorithm 733 This memo updates the "SHA" digest algorithm in the HTTP Digest 734 Algorithm Values [7] registry: 736 o Digest Algorithm: SHA 738 o Description: As specified in Section 3. 740 o Status: As specified in Section 3. 742 9.5. The "ID-SHA-256" Digest Algorithm 744 This memo registers the "ID-SHA-256" digest algorithm in the HTTP 745 Digest Algorithm Values [8] registry: 747 o Digest Algorithm: ID-SHA-256 749 o Description: As specified in Section 3. 751 o Status: As specified in Section 3. 753 9.6. The "ID-SHA-512" Digest Algorithm 755 This memo registers the "ID-SHA-512" digest algorithm in the HTTP 756 Digest Algorithm Values [9] registry: 758 o Digest Algorithm: ID-SHA-512 760 o Description: As specified in Section 3. 762 o Status: As specified in Section 3. 764 9.7. Changes compared to RFC5843 766 The status has been updated to "obsoleted" for both "SHA" and "MD5", 767 and their descriptions states that those algorithms are NOT 768 RECOMMENDED. 770 The status for all other algorithms have been updated to "standard". 772 The "ID-SHA-256" and "ID-SHA-512" algorithms have been added to the 773 registry. 775 9.8. Want-Digest Header Field Registration 777 This section registers the "Want-Digest" header field in the 778 "Permanent Message Header Field Names" registry ([RFC3864]). 780 Header field name: "Want-Digest" 782 Applicable protocol: http 784 Status: standard 786 Author/Change controller: IETF 788 Specification document(s): Section 4.1 of this document 790 9.9. Digest Header Field Registration 792 This section registers the "Digest" header field in the "Permanent 793 Message Header Field Names" registry ([RFC3864]). 795 Header field name: "Digest" 797 Applicable protocol: http 799 Status: standard 801 Author/Change controller: IETF 803 Specification document(s): Section 4.2 of this document 805 10. References 807 10.1. Normative References 809 [CMU-836068] 810 Carnagie Mellon University, Software Engineering 811 Institute, ., "MD5 Vulnerable to collision attacks", 812 December 2008, . 814 [FIPS180-1] 815 Department of Commerce, National., "NIST FIPS 180-1, 816 Secure Hash Standard", April 1995, 817 . 819 [FIPS180-3] 820 Department of Commerce, National., "NIST FIPS 180-3, 821 Secure Hash Standard", October 2008, 822 . 825 [IACR-2019-459] 826 Inria, France; Nanyang Technological University, 827 Singapore; Temasek Laboratories, Singapore, ., "From 828 Collisions to Chosen-Prefix Collisions Application to Full 829 SHA-1", May 2019, . 831 [NIST800-32] 832 Department of Commerce, National., "Introduction to Public 833 Key Technology and the Federal PKI Infrastructure", 834 February 2001, 835 . 838 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 839 DOI 10.17487/RFC1321, April 1992, 840 . 842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, 844 DOI 10.17487/RFC2119, March 1997, 845 . 847 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 848 RFC 3230, DOI 10.17487/RFC3230, January 2002, 849 . 851 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 852 Procedures for Message Header Fields", BCP 90, RFC 3864, 853 DOI 10.17487/RFC3864, September 2004, 854 . 856 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 857 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 858 . 860 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 861 Specifications: ABNF", STD 68, RFC 5234, 862 DOI 10.17487/RFC5234, January 2008, 863 . 865 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", 866 RFC 5789, DOI 10.17487/RFC5789, March 2010, 867 . 869 [RFC5843] Bryan, A., "Additional Hash Algorithms for HTTP Instance 870 Digests", RFC 5843, DOI 10.17487/RFC5843, April 2010, 871 . 873 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 874 Protocol (HTTP/1.1): Message Syntax and Routing", 875 RFC 7230, DOI 10.17487/RFC7230, June 2014, 876 . 878 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 879 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 880 DOI 10.17487/RFC7231, June 2014, 881 . 883 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 884 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 885 RFC 7233, DOI 10.17487/RFC7233, June 2014, 886 . 888 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 889 RFC 7405, DOI 10.17487/RFC7405, December 2014, 890 . 892 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 893 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 894 May 2017, . 896 [UNIX] The Open Group, ., "The Single UNIX Specification, Version 897 2 - 6 Vol Set for UNIX 98", February 1997. 899 10.2. Informative References 901 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 902 DOI 10.17487/RFC2818, May 2000, 903 . 905 [RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396, 906 DOI 10.17487/RFC7396, October 2014, 907 . 909 [SRI] Akhawe, D., Braun, F., Marier, F., and J. Weinberger, 910 "Subresource Integrity", June 2016. 912 10.3. URIs 914 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 916 [2] https://github.com/httpwg/http-extensions 918 [3] https://tools.ietf.org/html/rfc7231#section-3.1.2.1 920 [4] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml 922 [5] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml 924 [6] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml 926 [7] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml 928 [8] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml 930 [9] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml 932 Appendix A. Change Log 934 RFC EDITOR PLEASE DELETE THIS SECTION. 936 Appendix B. FAQ 938 1. Why remove all references to content-md5? 940 Those were unnecessary to understanding and using this spec. 942 2. Why remove references to instance manipulation? 944 Those were unnecessary for correctly using and applying the spec. 945 An example with Range Request is more than enough. This doc uses 946 the term "partial representation" which should group all those 947 cases. 949 3. How to use "Digest" with "PATCH" method? 951 The PATCH verb brings some complexities (eg. about representation 952 metadata headers, patch document format, ...), 954 * PATCH entity-headers apply to the patch document and MUST NOT 955 be applied to the target resource, see [RFC5789], Section 2. 957 * servers shouldn't assume PATCH semantics for generic media 958 types like "application/json" but should instead use a proper 959 content-type, eg [RFC7396] 961 * a "200 OK" response to a PATCH request would contain the 962 digest of the patched item, and the etag of the new object. 963 This behavior - tighly coupled to the application logic - 964 gives the client low probability of guessing the actual 965 outcome of this operation (eg. concurrent changes, ...) 967 4. Why remove references to delta-encoding? 969 Unnecessary for a correct implementation of this spec. The 970 revised spec can be nicely adapted to "delta encoding", but all 971 the references here to delta encoding don't add anything to this 972 RFC. Another job would be to refresh delta encoding. 974 5. Why remove references to Digest Authentication? 976 This RFC seems to me completely unrelated to Digest 977 Authentication but for the word "Digest". 979 6. What changes in "Want-Digest"? 980 We allow to use the "Want-Digest" in responses to advertise the 981 supported digest-algorithms and the inability to accept requests 982 with unsupported digest-algorithms. 984 7. Does this spec changes supported algorithms? 986 This RFC updates [RFC5843] which is still delegated for all 987 algorithms updates, and adds two more algorithms: ID-SHA-256 and 988 ID-SHA-512 which allows to send a checksum of a resource 989 representation with no content codings applied. 991 Acknowledgements 993 The vast majority of this document is inherited from [RFC3230], so 994 thanks to J. Mogul and A. Van Hoff for their great work. The 995 original idea of refreshing this document arose from an interesting 996 discussion with M. Nottingham, J. Yasskin and M. Thomson when 997 reviewing the MICE content coding. 999 Authors' Addresses 1001 Roberto Polli 1002 Team Digitale, Italian Government 1004 Email: robipolli@gmail.com 1006 Lucas Pardue 1007 Cloudflare 1009 Email: lucaspardue.24.7@gmail.com