[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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"

   <!doctype html>
   <html>
   ...

   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",
     '<!doctype html>\n<html>...'
   ]

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,
              <https://fetch.spec.whatwg.org/>.

   [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,
              <http://pubs.opengroup.org/onlinepubs/9699919799/
              basedefs/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.






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,
              <https://www.rfc-editor.org/info/rfc5280>.

   [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,
              <https://www.rfc-editor.org/info/rfc6960>.

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <https://www.rfc-editor.org/info/rfc6962>.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <https://www.rfc-editor.org/info/rfc7049>.

   [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,
              <https://www.rfc-editor.org/info/rfc7230>.

   [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,
              <https://www.rfc-editor.org/info/rfc7231>.

   [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,
              <https://www.rfc-editor.org/info/rfc7234>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <https://www.rfc-editor.org/info/rfc7540>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.



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,
              <https://www.rfc-editor.org/info/rfc2437>.

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,
              <https://www.rfc-editor.org/info/rfc6066>.

   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
              DOI 10.17487/RFC6454, December 2011,
              <https://www.rfc-editor.org/info/rfc6454>.




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,
              <https://www.rfc-editor.org/info/rfc7541>.

   [SRI]      Akhawe, D., Braun, F., Marier, F., and J. Weinberger,
              "Subresource Integrity", World Wide Web Consortium
              Recommendation REC-SRI-20160623, June 2016,
              <http://www.w3.org/TR/2016/REC-SRI-20160623>.

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

   <script src="https://jquery.com/jquery-1.2.3.min.js">

   Then to avoid the need to look up and connect to "jquery.com" in the
   critical path, "example.com" might PUSH that resource ([RFC7540],
   section 8.2), signed by "jquery.com".

A.2.  Explicit use of a content distributor for subresources

   In order to speed up loading but still maintain control over its
   content, an HTML page in a particular origin "O.com" could tell
   clients to load its subresources from an intermediate content
   distributor that's not authoritative, but require that those
   resources be signed by "O.com" so that the distributor couldn't
   modify the resources.  This is more constrained than the common CDN
   case where "O.com" has a CNAME granting the CDN the right to serve
   arbitrary content as "O.com".

   <img logicalsrc="https://O.com/img.png"
        physicalsrc="https://distributor.com/O.com/img.png">

   To make it easier to configure the right distributor for a given
   request, computation of the "physicalsrc" could be encapsulated in a
   custom element:

   <dist-img src="https://O.com/img.png"></dist-img>

   where the "<dist-img>" implementation generates an appropriate
   "<img>" based on, for example, a "<meta name="dist-base">" tag
   elsewhere in the page.

   This could be used for some of the same purposes as SRI
   (Appendix A.3).

   Note that the current proposal doesn't support this use case because
   there's no way aside from a Server Push to override the physical
   request URL.

A.3.  Subresource Integrity

   The W3C WebAppSec group is investigating using signatures [7] in
   [SRI].  They need a way to transmit the signature with the response,
   which this proposal could provide.

   However, their needs also differ in some significant ways:





Yasskin                   Expires June 8, 2018                 [Page 21]


Internet-Draft        Origin-signed HTTP Responses         December 2017


   1.  The "integrity="ed25519-[public-key]"" attribute and CSP-based
       ways of expressing a public key don't need the signing key to be
       also trusted to sign arbitrary content for an origin.

   2.  Some uses of SRI want to constrain subresources to be vouched for
       by a third-party, rather than just being signed by the
       subresource's author.

   While we can design this system to cover both origin-trusted and
   simple-key signatures, we should check that this is better than
   having two separate systems for the two kinds of signatures.

   Note that while the current proposal for SRI describes signing only
   the content of a resource, they may need to sign its name as well, to
   prevent security vulnerabilities [8].  The details of what they need
   to sign will affect whether and how they can use this proposal.

A.4.  Offline websites

   See https://github.com/WICG/webpackage [9] and
   [I-D.yasskin-dispatch-web-packaging].  This use requires origin-
   signed resources to be bundled.

Appendix B.  Requirements

B.1.  Proof of origin

   To verify that a thing came from a particular origin, for use in the
   same context as a TLS connection, we need someone to vouch for the
   signing key with as much verification as the signing keys used in
   TLS.  The obvious way to do this is to re-use the web PKI and CA
   ecosystem.

B.1.1.  Certificate constraints

   If we re-use existing TLS server certificates, we incur the risks
   that:

   1.  TLS server certificates must be accessible from online servers,
       so they're easier to steal than an offline key.  A package's
       signing key doesn't need to be online.

   2.  A server using an origin-trusted key for one purpose (e.g.  TLS)
       might accidentally sign something that looks like a package, or
       vice versa.

   If these risks are too high, we could define a new Extended Key Usage
   ([RFC5280], section 4.2.1.12) that requires CAs to issue new keys for



Yasskin                   Expires June 8, 2018                 [Page 22]


Internet-Draft        Origin-signed HTTP Responses         December 2017


   this purpose or a new certificate extension to do the same.  A new
   EKU would probably require CAs to also issue new intermediate
   certificates because of how browsers trust EKUs.  Both an EKU and a
   new extension take a long time to deploy and allow CAs to charge
   package-signers more than normal server operators, which will reduce
   adoption.

   The rest of this document will assume we can re-use existing TLS
   server certificates.

B.1.2.  Signature constraints

   In order to prevent an attacker who can convince the server to sign
   some resource from causing those signed bytes to be interpreted as
   something else, signatures here need to:

   1.  Avoid key types that are used for non-TLS protocols whose output
       could be confused with a signature.  That may be just the
       "rsaEncryption" OID from [RFC2437].

   2.  Use the same format as TLS's signatures, specified in
       [I-D.ietf-tls-tls13] section 4.4.3, with a context string that's
       specific to this use.

   The specification also needs to define which signing algorithm to
   use.  I expect to define that as a function from the key type,
   instead of allowing attacker-controlled data to specify it.

B.1.3.  Retrieving the certificate

   The client needs to be able to find the certificate vouching for the
   signing key, a chain from that certificate to a trusted root, and
   possibly other trust information like SCTs ([RFC6962]).  One approach
   would be to include the certificate and its chain in the signature
   metadata itself, but this wastes bytes when the same certificate is
   used for multiple HTTP responses.  If we decide to put the signature
   in an HTTP header, certificates are also unusually large for that
   context.

   Another option is to pass a URL that the client can fetch to retrieve
   the certificate and chain.  To avoid extra round trips in fetching
   that URL, it could be bundled (Appendix A.4) with the signed content
   or PUSHed (Appendix A.1) with it.  The risks from the
   "client_certificate_url" extension ([RFC6066] section 11.3) don't
   seem to apply here, since an attacker who can get a client to load a
   package and fetch the certificates it references, can also get the
   client to perform those fetches by loading other HTML.




Yasskin                   Expires June 8, 2018                 [Page 23]


Internet-Draft        Origin-signed HTTP Responses         December 2017


   To avoid using an unintended certificate with the same public key as
   the intended one, the content of the certificate chain should be
   included in the signed data, like TLS does ([I-D.ietf-tls-tls13],
   section 4.4.3).

B.2.  How much to sign

   The previous [I-D.thomson-http-content-signature] and
   [I-D.burke-content-signature] schemes signed just the content, while
   ([I-D.cavage-http-signatures] could also sign the response headers
   and the request method and path.  However, the same path, response
   headers, and content may mean something very different when retrieved
   from a different server.  Section 3.3 currently includes the whole
   request URL in the signature, but it's possible we need a more
   flexible scheme to allow some higher-level protocols to accept a
   less-signed URL.

   The question of whether to include other request headers--primarily
   the "accept*" family--is still open.  These headers need to be
   represented so that clients wanting a different language, say, can
   avoid using the wrong-language response, but it's not obvious that
   there's a security vulnerability if an attacker can spoof them.  For
   now, the proposal (Section 3) omits other request headers.

   In order to allow multiple clients to consume the same signed
   exchange, the exchange shouldn't include the exact request headers
   that any particular client sends.  For example, a Japanese resource
   wouldn't include

   accept-language: ja-JP, ja;q=0.9, en;q=0.8, zh;q=0.7, *;q=0.5

   Instead, it would probably include just

   accept-language: ja-JP, ja

   and clients would use the same matching logic as for PUSH_PROMISE
   [10] frame headers.

B.2.1.  Conveying the signed headers

   HTTP headers are traditionally munged by proxies, making it
   impossible to guarantee that the client will see the same sequence of
   bytes as the author wrote.  In the HTTPS world, we have more end-to-
   end header integrity, but it's still likely that there are enough
   TLS-terminating proxies that the author's signatures would tend to
   break before getting to the client.





Yasskin                   Expires June 8, 2018                 [Page 24]


Internet-Draft        Origin-signed HTTP Responses         December 2017


   There's also no way in current HTTP for the response to a client-
   initiated request ([RFC7540], section 8.1) to convey the request
   headers it expected to respond to.  A PUSH_PROMISE ([RFC7540],
   section 8.2) does not have this problem, and it would be possible to
   introduce a response header to convey the expected request headers.

   Since proxies don't modify unknown content types, we could wrap the
   original exchange into an "application/http2" format.  This could be
   as simple as a series of HTTP/2 frames, or could

   1.  Allow longer contiguous bodies than HTTP/2's 16MB frame limit
       [11], and

   2.  Use better compression than [RFC7541] for the non-confidential
       headers.  Note that header compression can probably share a
       compression state across a single signed exchange, but needs a
       mechanism like [I-D.vkrasnov-h2-compression-dictionaries] to use
       any compression state from other responses.

   To help the PUSHed subresources use case (Appendix A.1), we might
   also want to extend the "PUSH_PROMISE" frame type to include a
   signature, and that could tell intermediates not to change the
   ensuing headers.

B.3.  Response lifespan

   A normal HTTPS response is authoritative only for one client, for as
   long as its cache headers say it should live.  A signed exchange can
   be re-used for many clients, and if it was generated while a server
   was compromised, it can continue compromising clients even if their
   requests happen after the server recovers.  This signing scheme needs
   to mitigate that risk.

B.3.1.  Certificate revocation

   Certificates are mis-issued and private keys are stolen, and in
   response clients need to be able to stop trusting these certificates
   as promptly as possible.  Online revocation checks don't work [12],
   so the industry has moved to pushed revocation lists and stapled OCSP
   responses [RFC6066].

   Pushed revocation lists work as-is to block trust in the certificate
   signing an exchange, but the signatures need an explicit strategy to
   staple OCSP responses.  One option is to extend the certificate
   download (Appendix B.1.3) to include the OCSP response too, perhaps
   in the TLS 1.3 CertificateEntry [13] format.





Yasskin                   Expires June 8, 2018                 [Page 25]


Internet-Draft        Origin-signed HTTP Responses         December 2017


B.3.2.  Response downgrade attacks

   The signed content in a response might be vulnerable to attacks, such
   as XSS, or might simply be discovered to be incorrect after
   publication.  Once the author fixes those vulnerabilities or
   mistakes, clients should stop trusting the old signed content in a
   reasonable amount of time.  Similar to certificate revocation, I
   expect the best option to be stapled "this version is still valid"
   assertions with short expiration times.

   These assertions could be structured as:

   1.  A signed minimum version number or timestamp for a set of request
       headers: This requires that signed responses need to include a
       version number or timestamp, but allows a server to provide a
       single signature covering all valid versions.

   2.  A replacement for the whole exchange's signature.  This requires
       the author to separately re-sign each valid version and requires
       each version to include a different update URL, but allows
       intermediates to serve less data.  This is the approach taken in
       Section 3.

   3.  A replacement for the exchange's signature and an update for the
       embedded "expires" and related cache-control HTTP headers
       [RFC7234].  This naturally extends authors' intuitions about
       cache expiration and the existing cache revalidation behavior to
       signed exchanges.  This is sketched and its downsides explored in
       Appendix C.

   The signature also needs to include instructions to intermediates for
   how to fetch updated validity assertions.

Appendix C.  Determining validity using cache control

   This draft could expire signature validity using the normal HTTP
   cache control headers ([RFC7234]) instead of embedding an expiration
   date in the signature itself.  This section specifies how that would
   work, and describes why I haven't chosen that option.

   The signatures in the "Signature" header field (Section 3.2) would no
   longer contain "date" or "expires" fields.

   The validity-checking algorithm (Section 3.6) would initialize "date"
   from the resource's "Date" header field ([RFC7231], section 7.1.1.2)
   and initialize "expires" from either the "Expires" header field
   ([RFC7234] section 5.3) or the "Cache-Control" header field's "max-
   age" directive ([RFC7234] section 5.2.2.8) (added to "date"),



Yasskin                   Expires June 8, 2018                 [Page 26]


Internet-Draft        Origin-signed HTTP Responses         December 2017


   whichever is present, preferring "max-age" (or failing) if both are
   present.

   Validity updates (Section 3.7) would include a list of replacement
   response header fields.  For each header field name in this list, the
   client would remove matching header fields from the stored exchange's
   response header fields.  Then the client would append the replacement
   header fields to the stored exchange's response header fields.

C.1.  Example of updating cache control

   For example, given a stored exchange of:

   GET https://example.com/ HTTP/1.1
   accept = */*

   HTTP/1.1 200
   date = Mon, 20 Nov 2017 10:00:00 UTC
   content-type = text/html
   date = Tue, 21 Nov 2017 10:00:00 UTC
   expires = Sun, 26 Nov 2017 10:00:00 UTC

   <!doctype html>
   <html>
   ...

   And an update listing the following headers:

   expires = Fri, 1 Dec 2017 10:00:00 UTC
   date = Sat, 25 Nov 2017 10:00:00 UTC

   The resulting stored exchange would be:

   GET https://example.com/ HTTP/1.1
   accept = */*

   HTTP/1.1 200
   content-type = text/html
   expires = Fri, 1 Dec 2017 10:00:00 UTC
   date = Sat, 25 Nov 2017 10:00:00 UTC

   <!doctype html>
   <html>
   ...







Yasskin                   Expires June 8, 2018                 [Page 27]


Internet-Draft        Origin-signed HTTP Responses         December 2017


C.2.  Downsides of updating cache control

   In an exchange with multiple signatures, using cache control to
   expire signatures forces all signatures to initially live for the
   same period.  Worse, the update from one signature's "validityUrl"
   might not match the update for another signature.  Clients would need
   to maintain a current set of headers for each signature, and then
   decide which set to use when actually parsing the resource itself.

   This need to store and reconcile multiple sets of headers for a
   single signed exchange argues for embedding a signature's lifetime
   into the signature.

Appendix D.  Acknowledgements

   Thanks to Ilari Liusvaara, Mark Nottingham, Ryan Sleevi, and Yoav
   Weiss for comments that improved this draft.

Author's Address

   Jeffrey Yasskin
   Google

   Email: jyasskin@chromium.org



























Yasskin                   Expires June 8, 2018                 [Page 28]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/