http J. Yasskin Internet-Draft Google Intended status: Standards Track December 05, 2017 Expires: June 8, 2018 Origin-signed HTTP Responses draft-yasskin-http-origin-signed-responses-01 Abstract This document explores how a server can send particular responses that are authoritative for an origin, when the server itself is not authoritative for that origin. For now, the appendices containing use cases and requirements should be treated as more confident than the proposal itself. Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. The source code and issues list for this draft can be found in https://github.com/WICG/webpackage [2]. 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 https://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 June 8, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Yasskin Expires June 8, 2018 [Page 1] Internet-Draft Origin-signed HTTP Responses December 2017 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Straw proposal . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. The Signed-Headers Header . . . . . . . . . . . . . . . . 4 3.2. The Signature Header . . . . . . . . . . . . . . . . . . 5 3.2.1. Open Questions . . . . . . . . . . . . . . . . . . . 6 3.3. Significant parts of an exchange . . . . . . . . . . . . 6 3.3.1. Open Questions . . . . . . . . . . . . . . . . . . . 6 3.4. CBOR representation of an exchange . . . . . . . . . . . 7 3.4.1. Example . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Canonical CBOR serialization . . . . . . . . . . . . . . 8 3.6. Signature validity . . . . . . . . . . . . . . . . . . . 9 3.6.1. Validating a certificate chain for an authority . . . 12 3.6.2. Open Questions . . . . . . . . . . . . . . . . . . . 13 3.7. Updating signature validity . . . . . . . . . . . . . . . 13 3.7.1. Examples . . . . . . . . . . . . . . . . . . . . . . 14 4. Security considerations . . . . . . . . . . . . . . . . . . . 15 4.1. Aspects of the straw proposal . . . . . . . . . . . . . . 16 5. Privacy considerations . . . . . . . . . . . . . . . . . . . 16 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 19 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Use cases . . . . . . . . . . . . . . . . . . . . . 20 A.1. PUSHed subresources . . . . . . . . . . . . . . . . . . . 20 A.2. Explicit use of a content distributor for subresources . 21 A.3. Subresource Integrity . . . . . . . . . . . . . . . . . . 21 A.4. Offline websites . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 22 B.1. Proof of origin . . . . . . . . . . . . . . . . . . . . . 22 B.1.1. Certificate constraints . . . . . . . . . . . . . . . 22 B.1.2. Signature constraints . . . . . . . . . . . . . . . . 23 B.1.3. Retrieving the certificate . . . . . . . . . . . . . 23 B.2. How much to sign . . . . . . . . . . . . . . . . . . . . 24 B.2.1. Conveying the signed headers . . . . . . . . . . . . 24 Yasskin Expires June 8, 2018 [Page 2] Internet-Draft Origin-signed HTTP Responses December 2017 B.3. Response lifespan . . . . . . . . . . . . . . . . . . . . 25 B.3.1. Certificate revocation . . . . . . . . . . . . . . . 25 B.3.2. Response downgrade attacks . . . . . . . . . . . . . 26 Appendix C. Determining validity using cache control . . . . . . 26 C.1. Example of updating cache control . . . . . . . . . . . . 27 C.2. Downsides of updating cache control . . . . . . . . . . . 28 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction When I presented Web Packaging to DISPATCH [3], folks thought it would make sense to split it into a way to sign individual HTTP responses as coming from a particular origin, and separately a way to bundle a collection of HTTP responses. This document explores the constraints on any method of signing HTTP responses and sketches a possible solution to the constraints. 2. Terminology Author The entity that controls the server for a particular origin [RFC6454]. The author can get a CA to issue certificates for their private keys and can run a TLS server for their origin. Exchange (noun) An HTTP request/response pair. This can either be a request from a client and the matching response from a server or the request in a PUSH_PROMISE and its matching response stream. Defined by [RFC7540] section 8. Intermediate An entity that fetches signed HTTP exchanges from an author or another intermediate and forwards them to another intermediate or a client. Client An entity that uses a signed HTTP exchange and needs to be able to prove that the author vouched for it as coming from its claimed origin. Unix time Defined by [POSIX] section 4.16 [4]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Yasskin Expires June 8, 2018 [Page 3] Internet-Draft Origin-signed HTTP Responses December 2017 3. Straw proposal As a response to an HTTP request or as a Server Push ([RFC7540], section 8.2) the server MAY include a "Signed-Headers" header field (Section 3.1) identifying significant (Section 3.3) header fields and a "Signature" header field (Section 3.2) holding a list of one or more parameterised signatures that vouch for the content of the response. The client categorizes each signature as "valid" or "invalid" by validating that signature with its certificate or public key and other metadata against the significant headers and content (Section 3.6). This validity then informs higher-level protocols. Each signature is parameterised with information to let a client fetch assurance that a signed exchange is still valid, in the face of revoked certificates and newly-discovered vulnerabilities. This assurance can be bundled back into the signed exchange and forwarded to another client, which won't have to re-fetch this validity information for some period of time. 3.1. The Signed-Headers Header The "Signed-Headers" header field identifies an ordered list of response header fields to include in a signature. The request URL and response status are included unconditionally. This allows a TLS- terminating intermediate to reorder headers without breaking the signature. This _can_ also allow the intermediate to add headers that will be ignored by some higher-level protocols, but Section 3.6 provides a hook to let other higher-level protocols reject such insecure headers. This header field appears once instead of being incorporated into the signatures' parameters because the significant header fields need to be consistent across all signatures of an exchange, to avoid forcing higher-level protocols to merge the header field lists of valid signatures. See Appendix B.2 for a discussion of why only the URL from the request is included and not other request headers. "Signed-Headers" is a Structured Header as defined by [I-D.ietf-httpbis-header-structure]. Its value MUST be a list ([I-D.ietf-httpbis-header-structure], section 4.8) of lowercase strings ([I-D.ietf-httpbis-header-structure], section 4.2) naming HTTP response header fields. Pseudo-header field names ([RFC7540], section 8.1.2.1) MUST not appear in this list. Yasskin Expires June 8, 2018 [Page 4] Internet-Draft Origin-signed HTTP Responses December 2017 Higher-level protocols SHOULD place requirements on the minimum set of headers to include in the "Signed-Headers" header field. 3.2. The Signature Header The "Signature" header field conveys a list of signatures for an exchange, each one accompanied by information about how to determine the authority of and refresh that signature. The "Signature" header is a Structured Header as defined by [I-D.ietf-httpbis-header-structure]. Its value MUST be a list ([I-D.ietf-httpbis-header-structure], section 4.8) of parameterised labels ([I-D.ietf-httpbis-header-structure], section 4.4). Each parameterised label MUST have parameters named "sig", "validityUrl", "date", and "expires", and either "certUrl" and "certSha256" parameters or an "ed25519Key" parameter. This specification gives no meaning to the label itself, which can be used as a human-readable identifier for the signature (see Section 3.2.1, Paragraph 1). The present parameters MUST have the following values: "sig" Binary content ([I-D.ietf-httpbis-header-structure], section 4.5) holding the signature of most of these parameters and the significant parts of the exchange (Section 3.3). "certUrl" A string ([I-D.ietf-httpbis-header-structure], section 4.2) containing a valid URL string [5]. "certSha256" Binary content ([I-D.ietf-httpbis-header-structure], section 4.5) holding the SHA-256 hash of the first certificate found at "certUrl". "ed25519Key" Binary content ([I-D.ietf-httpbis-header-structure], section 4.5) holding an Ed25519 public key ([RFC8032]). "validityUrl" A string ([I-D.ietf-httpbis-header-structure], section 4.2) containing a valid URL string [6]. "date" and "expires" An unsigned integer ([I-D.ietf-httpbis-header-structure], section 4.1) representing a Unix time. The "certUrl" and "validityUrl" parameters are _not_ signed, so intermediates can update them with pointers to cached versions. Yasskin Expires June 8, 2018 [Page 5] Internet-Draft Origin-signed HTTP Responses December 2017 3.2.1. Open Questions [I-D.ietf-httpbis-header-structure] provides a way to parameterise labels but not other supported types like binary content. If the "Signature" header field is notionally a list of parameterised signatures, maybe we should add a "parameterised binary content" type. Should the certUrl and validityUrl be lists so that intermediates can offer a cache without losing the original URLs? Putting lists in dictionary fields is more complex than [I-D.ietf-httpbis-header-structure] allows, so they're single items for now. Should "validityUrl" be signed or optionally signed so that an exchange's author can prevent an intermediate from removing it, which would prevent clients from sharing the exchange among themselves without going back to the intermeidate? 3.3. Significant parts of an exchange The significant parts of an exchange are: o The method ([RFC7231], section 4) and effective request URI ([RFC7230], section 5.5) of the request. o The response status code ([RFC7231], section 6) and the response header fields whose names are listed in that exchange's "Signed- Headers" header field (Section 3.1), in the order they appear in that header field. If a response header field name from "Signed- Headers" does not appear in the exchange's response header fields, the exchange has no significant parts. o The exchange's payload body ([RFC7230], section 3.3). Note that the payload body is the message body with any transfer encodings removed. If the exchange's "Signed-Headers" header field is not present, doesn't parse as a Structured Header ([I-D.ietf-httpbis-header-structure]) or doesn't follow the constraints on its value described in Section 3.1, the exchange has no significant parts. 3.3.1. Open Questions Do the significant parts of an exchange need to include the "Signed- Headers" header field itself? Yasskin Expires June 8, 2018 [Page 6] Internet-Draft Origin-signed HTTP Responses December 2017 3.4. CBOR representation of an exchange To sign an exchange, it needs to be serialized into a byte string. Since intermediaries and distributors (Appendix A.2) might rearrange, add, or just reserialize headers, and this can change the HPACK encoding, we can't use the literal bytes of the header frames as this serialization. Instead, this section defines a CBOR representation that can be embedded into other CBOR, canonically serialized (Section 3.5), and then signed. The CBOR representation of an exchange is the result of the following algorithm: 1. Let "exchange" be the exchange. This is expected to be the significant parts (Section 3.3) of some other exchange. 2. Return a CBOR ([RFC7049]) array with the following content: 1. The text string "request". 2. The array consisting of the following items: 1. The byte string ':method'. 2. The byte string containing the request's method. 3. The byte string ':url'. 4. The byte string containing the request's effective request URI. 3. The text string "response". 4. The array consisting of the initial two items 1. The byte string ':status'. 2. The byte string containing the response's 3-digit status code. Followed by the appended items from, for each response header field in "exchange", in order: 1. Append the header field's name as a byte string. 2. Append the header field's value as a byte string. 5. The text string "payload". Yasskin Expires June 8, 2018 [Page 7] Internet-Draft Origin-signed HTTP Responses December 2017 6. The byte string containing the response's payload body ([RFC7230], section 3.3). Note that the payload body is the message body with any transfer encodings removed. 3.4.1. Example Given the HTTP exchange: GET https://example.com/ HTTP/1.1 accept = */* HTTP/1.1 200 content-type = text/html signed-headers = "content-type" ... The cbor representation consists of the following item, represented using the extended diagnostic notation from [I-D.ietf-cbor-cddl] appendix G: [ "request", [ ':method', 'GET', ':url', 'https://example.com/' ], "response", [ ':status', '200', 'content-type', 'text/html' ], "payload", '\n...' ] 3.5. Canonical CBOR serialization Within this specification, the canonical serialization of a CBOR item uses the following rules derived from section 3.9 of [RFC7049]: o Integers and the lengths of arrays and strings MUST use the smallest possible encoding. o Items MUST NOT be encoded with indefinite length. Yasskin Expires June 8, 2018 [Page 8] Internet-Draft Origin-signed HTTP Responses December 2017 Note: this specification does not use CBOR maps, so the map ordering rules aren't necessary. This specification also doesn't use floating point, tags, or other more complex data types, so it doesn't need rules to canonicalize those either. 3.6. Signature validity The client MUST parse the "Signature" header field as the list of parameterised values described in Section 3.2 ([I-D.ietf-httpbis-header-structure], section 4.8.1). If an error is thrown during this parsing, the exchange has no valid signatures. Otherwise, each member of this list represents a signature with parameters. The client MUST use the following algorithm to determine whether each signature with parameters is invalid or potentially-valid. Potentially-valid results include: o The signed parts of the exchange so that higher-level protocols can avoid relying on unsigned headers, and o Either a certificate chain or a public key so that a higher-level protocol can determine whether it's actually valid. This algorithm accepts a "forceFetch" flag that avoids the cache when fetching URLs. A client that determines that a potentially-valid certificate chain is actually invalid due to expired OCSP responses MAY retry with "forceFetch" set to retrieve updated OCSPs from the original server. This algorithm also accepts an "allResponseHeaders" flag, which insists that there are no non-significant response header fields in the exchange. 1. Let "originalExchange" be the signature's exchange. 2. Let "exchange" be the significant parts (Section 3.3) of "originalExchange". If "originalExchange" has no significant parts, then return "invalid". 3. If "allResponseHeaders" is set and the response headers fields in "originalExchange" are a proper superset of the response header fields in "exchange", then return "invalid". 4. Let: * "signature" be the signature (binary content in the parameterised value's "sig" parameter). Yasskin Expires June 8, 2018 [Page 9] Internet-Draft Origin-signed HTTP Responses December 2017 * "certUrl" be the signature's "certUrl" parameter, if any. * "certSha256" be the signature's "certSha256" parameter, if any. * "ed25519Key" be the signature's "ed25519Key" parameter, if any. * "date" be the signature's "date" parameter, interpreted as a Unix time. * "expires" be the signature's "expires" parameter, interpreted as a Unix time. 5. Set "publicKey" and "signing-alg" depending on which key fields are present: 1. If "certUrl" is present: 1. Let "certificate-chain" be the result of fetching ([FETCH]) "certUrl" and parsing it as a TLS 1.3 Certificate message ([I-D.ietf-tls-tls13], section 4.4.2) containing X.509v3 certificates. If "forceFetch" is _not_ set, the fetch can be fulfilled from a cache using normal HTTP semantics [RFC7234]. If this fetch or parse fails, return "invalid". 2. Let "main-certificate" be the first certificate in "certificate-chain". 3. If the SHA-256 hash of "main-certificate"'s "cert_data" is not equal to "certSha256", return "invalid". See the open questions (Section 3.6.2, Paragraph 1). 4. Set "publicKey" to "main-certificate"'s public key 5. The client MUST define a partial function from public key types to signing algorithms, and this function must at the minimum include the following mappings: RSA, 2048 bits: rsa_pss_sha256 as defined in Section 4.2.3 of [I-D.ietf-tls-tls13]. EC, with the secp256r1 curve: ecdsa_secp256r1_sha256 as defined in Section 4.2.3 of [I-D.ietf-tls-tls13]. EC, with the secp384r1 curve: ecdsa_secp384r1_sha384 as defined in Section 4.2.3 of [I-D.ietf-tls-tls13]. Yasskin Expires June 8, 2018 [Page 10] Internet-Draft Origin-signed HTTP Responses December 2017 Set "signing-alg" to the result of applying this function to type of "main-certificate"'s public key. If the function is undefined on this input, return "invalid". 2. If "ed25519Key" is present, set "publicKey" to "ed25519Key" and "signing-alg" to ed25519, as defined by [RFC8032] 6. If "expires" is more than 7 days (604800 seconds) after "date", return "invalid". 7. If the current time is before "date" or after "expires", return "invalid". 8. Let "message" be the concatenation of the following byte strings. This matches the [I-D.ietf-tls-tls13] format to avoid cross- protocol attacks when TLS certificates are used to sign manifests. 1. A string that consists of octet 32 (0x20) repeated 64 times. 2. A context string: the ASCII encoding of "HTTP Exchange". 3. A single 0 byte which serves as a separator. 4. The bytes of the canonical CBOR serialization (Section 3.5) of a CBOR array consisting of: 1. The text string "certSha256". 2. The byte string "certSha256". 3. The text string "date". 4. The integer value of "date". 5. The text string "expires". 6. The integer value of "expires". 7. The text string "exchange". 8. The CBOR representation (Section 3.4) of "exchange". See the open questions (Section 3.6.2, Paragraph 2). 9. If "signature" is "message"'s signature by "main-certificate"'s public key using "signing-alg", return "potentially-valid" with "exchange" and whichever is present of "certificate-chain" or "ed25519Key". Otherwise, return "invalid". Yasskin Expires June 8, 2018 [Page 11] Internet-Draft Origin-signed HTTP Responses December 2017 3.6.1. Validating a certificate chain for an authority [RFC7540] section 8.2 includes the rule: The server MUST include a value in the :authority pseudo-header field for which the server is authoritative (see Section 10.1). A client MUST treat a PUSH_PROMISE for which the server is not authoritative as a stream error (Section 5.4.2) of type PROTOCOL_ERROR. If the Server Push contains a signed exchange for which the server is not authoritative, instead of treating it as a stream error, the client MAY search for a signature for which the following algorithm returns "valid". If such a signature is found, the client MAY treat the server as authoritative for this particular exchange and store the exchange as described by [RFC7540]. If not, the client MUST treat the exchange as a stream error as described by [RFC7540]. 1. Run Section 3.6 over the signature with the "allResponseHeaders" flag set, getting "exchange" and "certificate-chain" back. If this returned "invalid" or didn't return a certificate chain, return "invalid". 2. Let "authority" be the host component of "exchange"'s effective request URI. 3. Validate the "certificate-chain" using the following substeps. If any of them fail, re-run Section 3.6 once over the signature with both the "forceFetch" flag and the "allResponseHeaders" flag set, and restart from step 2. If a substep fails again, return "invalid". 1. Use "certificate-chain" to validate that its first entry, "main-certificate" is trusted as "authority"'s server certificate ([RFC5280] and other undocumented conventions). Let "path" be the path that was used from the "main- certificate" to a trusted root, including the "main- certificate" but excluding the root. 2. Validate that all certificates in "path" include "status_request" extensions with valid OCSP responses. ([RFC6960]) 3. Validate that all certificates in "path" include "signed_certificate_timestamp" extensions containing valid SCTs from trusted logs. ([RFC6962]) 4. Return "valid". Yasskin Expires June 8, 2018 [Page 12] Internet-Draft Origin-signed HTTP Responses December 2017 3.6.2. Open Questions TLS 1.3 signs the entire certificate chain, but doing that here would preclude updating the OCSP signatures without replacing all signatures using that chain at the same time. What attack do I allow by hashing only the end-entity certificate? Including the entire exchange in the signed data forces a client to download the whole thing before trusting any of it. [I-D.thomson-http-mice] is designed to let us check the validity of just the "MI" header up front and then incrementally check blocks of the payload as they arrive. What's the best way to integrate that? Maybe add a flag to the "Signature" header field or its signatures saying that the payload is guarded by some other header field, so isn't included in the significant parts (Section 3.3). 3.7. Updating signature validity Both OCSP responses and signatures are designed to expire a short time after they're signed, so that revoked certificates and signed exchanges with known vulnerabilities are distrusted promptly. This specification provides no way to update OCSP responses by themselves. Instead, clients need to re-fetch the "certUrl" (Section 3.6, Paragraph 4) to get a chain including newer OCSPs. The "validityUrl" parameter (Paragraph 5) of the signatures provides a way to fetch new signatures or learn where to fetch a complete updated package. Each version of a signed exchange SHOULD have its own validity URLs, since each version needs different signatures and becomes obsolete at different times. The resource at a "validityUrl" is "validity data", a CBOR map matching the following CDDL ([I-D.ietf-cbor-cddl]): validity = { ? signatures: [ + bytes ] ? update: { url: text, ? size: uint, } ] The elements of the "signatures" array are header field values meant to replace the signatures within the "Signature" header field pointing to this validity data. If the signed exchange contains a Yasskin Expires June 8, 2018 [Page 13] Internet-Draft Origin-signed HTTP Responses December 2017 bug severe enough that clients need to stop using the content, the "signatures" array MUST NOT be present. The "update" map gives a location to update the entire signed exchange and an estimate of the size of the resource at that URL. If the signed exchange is currently the most recent version, the "update" SHOULD NOT be present. If both the "signatures" and "update" fields are present, clients can use the estimated size to decide whether to update the whole resource or just its signatures. 3.7.1. Examples For example, if a signed exchange has the following "Signature" header field (written as multiple fields for convenience): Signature: sig1; sig=*MEUCIQDXlI2gN3RNBlgFiuRNFpZXcDIaUpX6HIEwcZEc0cZYLAIga9DsVOMM+g5YpwEBdGW3sS+bvnmAJJiSMwhuBdqp5UY; validityUrl="https://example.com/resource.validity"; certUrl="https://example.com/certs"; certSha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI; date=1511128380; expires=1511560380 Signature: sig2; sig=*MEQCIGjZRqTRf9iKNkGFyzRMTFgwf/BrY2ZNIP/dykhUV0aYAiBTXg+8wujoT4n/W+cNgb7pGqQvIUGYZ8u8HZJ5YH26Qg; validityUrl="https://example.com/resource.validity"; certUrl="https://example.com/certs"; certSha256=*kQAA8u33cZRTy7RHMO4+dv57baZL48SYA2PqmYvPPbg; date=1511301183; expires=1511905983 Signature: sig3; sig=*MEYCIQCNxJzn6Rh2fNxsobktir8TkiaJYQFhWTuWI1i4PewQaQIhAMs2TVjc4rTshDtXbgQEOwgj2mRXALhfXPztXgPupii+; validityUrl="https://thirdparty.example.com/resource.validity"; certUrl="https://thirdparty.example.com/certs"; certSha256=*UeOwUPkvxlGRTyvHcsMUN0A2oNsZbU8EUvg8A9ZAnNc; date=1511301183; expires=1511905983 https://example.com/resource.validity might contain: Yasskin Expires June 8, 2018 [Page 14] Internet-Draft Origin-signed HTTP Responses December 2017 { "signatures": [ 'sig4; ' 'sig=*MEQCIC/I9Q+7BZFP6cSDsWx43pBAL0ujTbON/+7RwKVk+ba5AiB3FSFLZqpzmDJ0NumNwN04pqgJZE99fcK86UjkPbj4jw; ' 'validityUrl="https://example.com/resource.validity"; ' 'certUrl="https://example.com/certs"; ' 'certSha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI; ' 'date=1511467200; expires=1511985600' ], "update": { "url": "https://example.com/resource", "size": 5557452 } } This indicates that the first two of the original signatures (the ones with a validityUrl of "https://example.com/resource.validity") can be replaced with a single new signature. The signatures of the updated signed exchange would be: Signature: sig4; sig=*MEQCIC/I9Q+7BZFP6cSDsWx43pBAL0ujTbON/+7RwKVk+ba5AiB3FSFLZqpzmDJ0NumNwN04pqgJZE99fcK86UjkPbj4jw; validityUrl="https://example.com/resource.validity"; certUrl="https://example.com/certs"; certSha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI; date=1511467200; expires=1511985600 Signature: sig3; sig=*MEYCIQCNxJzn6Rh2fNxsobktir8TkiaJYQFhWTuWI1i4PewQaQIhAMs2TVjc4rTshDtXbgQEOwgj2mRXALhfXPztXgPupii+; validityUrl="https://thirdparty.example.com/resource.validity"; certUrl="https://thirdparty.example.com/certs"; certSha256=*UeOwUPkvxlGRTyvHcsMUN0A2oNsZbU8EUvg8A9ZAnNc; date=1511301183; expires=1511905983 https://example.com/resource.validity could also expand the set of signatures if its "signatures" array contained more than 2 elements. 4. Security considerations Authors MUST NOT include confidential information in a signed response that an untrusted intermediate could forward, since the response is only signed and not encrypted. Intermediates can read the content. Relaxing the requirement to consult DNS when determining authority for an origin means that an attacker who possesses a valid certificate no longer needs to be on-path to redirect traffic to them; instead of modifying DNS, they need only convince the user to visit another Web site in order to serve responses signed as the Yasskin Expires June 8, 2018 [Page 15] Internet-Draft Origin-signed HTTP Responses December 2017 target. This consideration and mitigations for it are shared by [I-D.ietf-httpbis-origin-frame]. Signing a bad response can affect more users than simply serving a bad response, since a served response will only affect users who make a request while the bad version is live, while an attacker can forward a signed response until its signature expires. Authors should consider shorter signature expiration times than they use for cache expiration times. An attacker with temporary access to a signing oracle can sign "still valid" assertions with arbitrary timestamps and expiration times. As a result, when a signing oracle is removed, the keys it provided access to SHOULD be revoked so that, even if the attacker used them to sign future-dated package validity assertions, the key's OCSP assertions will expire, causing the package as a whole to become untrusted. 4.1. Aspects of the straw proposal The use of a single "Signed-Headers" header field prevents us from signing aspects of the request other than its effective request URI ([RFC7230], section 5.5). For example, if an author signs both "Content-Encoding: br" and "Content-Encoding: gzip" variants of a response, what's the impact if an attacker serves the brotli one for a request with "Accept-Encoding: gzip"? The simple form of "Signed-Headers" also prevents us from signing less than the full request URL. The SRI use case (Appendix A.3) may benefit from being able to leave the authority less constrained. Section 3.6 can succeed when some delivered headers aren't included in the signed set. This accommodates current TLS-terminating intermediates and may be useful for SRI (Appendix A.3), but is risky for trusting cross-origin responses (Appendix A.1, Appendix A.2, and Appendix A.4). Section 3.6.1 requires all headers to be included in the signature before trusting cross-origin pushed resources, at Ryan Sleevi's recommendation. 5. Privacy considerations Normally, when a client fetches "https://o1.com/resource.js", "o1.com" learns that the client is interested in the resource. If "o1.com" signs "resource.js", "o2.com" serves it as "https://o2.com/ o1resource.js", and the client fetches it from there, then "o2.com" learns that the client is interested, and if the client executes the Javascript, that could also report the client's interest back to "o1.com". Yasskin Expires June 8, 2018 [Page 16] Internet-Draft Origin-signed HTTP Responses December 2017 Often, "o2.com" already knew about the client's interest, because it's the entity that directed the client to "o1resource.js", but there may be cases where this leaks extra information. For non-executable resource types, a signed response can improve the privacy situation by hiding the client's interest from the original author. 6. IANA considerations TODO: possibly register the validityUrl format. 7. References 7.1. Normative References [FETCH] WHATWG, "Fetch", December 2017, . [I-D.ietf-cbor-cddl] Birkholz, H., Vigano, C., and C. Bormann, "Concise data definition language (CDDL): a notational convention to express CBOR data structures", draft-ietf-cbor-cddl-00 (work in progress), July 2017. [I-D.ietf-httpbis-header-structure] Nottingham, M. and P. Kamp, "Structured Headers for HTTP", draft-ietf-httpbis-header-structure-02 (work in progress), November 2017. [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-22 (work in progress), November 2017. [POSIX] IEEE and The Open Group, "The Open Group Base Specifications Issue 7", name IEEE, value 1003.1-2008, 2016 Edition, 2016, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Yasskin Expires June 8, 2018 [Page 17] Internet-Draft Origin-signed HTTP Responses December 2017 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Yasskin Expires June 8, 2018 [Page 18] Internet-Draft Origin-signed HTTP Responses December 2017 7.2. Informative References [I-D.burke-content-signature] Burke, B., "HTTP Header for digital signatures", draft- burke-content-signature-00 (work in progress), March 2011. [I-D.cavage-http-signatures] Cavage, M. and M. Sporny, "Signing HTTP Messages", draft- cavage-http-signatures-09 (work in progress), November 2017. [I-D.ietf-httpbis-origin-frame] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", draft-ietf-httpbis-origin-frame-04 (work in progress), August 2017. [I-D.thomson-http-content-signature] Thomson, M., "Content-Signature Header Field for HTTP", draft-thomson-http-content-signature-00 (work in progress), July 2015. [I-D.thomson-http-mice] Thomson, M., "Merkle Integrity Content Encoding", draft- thomson-http-mice-02 (work in progress), October 2016. [I-D.vkrasnov-h2-compression-dictionaries] Krasnov, V., "Compression Dictionaries for HTTP/2", draft- vkrasnov-h2-compression-dictionaries-02 (work in progress), March 2017. [I-D.yasskin-dispatch-web-packaging] Yasskin, J., "Web Packaging", draft-yasskin-dispatch-web- packaging-00 (work in progress), June 2017. [RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, DOI 10.17487/RFC2437, October 1998, . [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, . Yasskin Expires June 8, 2018 [Page 19] Internet-Draft Origin-signed HTTP Responses December 2017 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, . [SRI] Akhawe, D., Braun, F., Marier, F., and J. Weinberger, "Subresource Integrity", World Wide Web Consortium Recommendation REC-SRI-20160623, June 2016, . 7.3. URIs [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [2] https://github.com/WICG/webpackage [3] https://datatracker.ietf.org/doc/minutes-99-dispatch/ [4] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ V1_chap04.html#tag_04_16 [5] https://url.spec.whatwg.org/#valid-url-string [6] https://url.spec.whatwg.org/#valid-url-string [7] https://github.com/mikewest/signature-based-sri [8] https://github.com/mikewest/signature-based-sri/issues/5 [9] https://github.com/WICG/webpackage [10] https://tools.ietf.org/html/rfc7540#section-8.2 [11] https://tools.ietf.org/html/rfc7540#section-4.2 [12] https://www.imperialviolet.org/2012/02/05/crlsets.html [13] https://tlswg.github.io/tls13-spec/draft-ietf-tls- tls13.html#ocsp-and-sct Appendix A. Use cases A.1. PUSHed subresources To reduce round trips, a server might use HTTP/2 PUSH to inject a subresource from another server into the client's cache. If anything about the subresource is expired or can't be verified, the client would fetch it from the original server. Yasskin Expires June 8, 2018 [Page 20] Internet-Draft Origin-signed HTTP Responses December 2017 For example, if "https://example.com/index.html" includes