idnits 2.17.1 

draft-yasskin-http-origin-signed-responses-00.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document date (August 31, 2017) is 2430 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '3' on line 474

  -- Looks like a reference, but probably isn't: '4' on line 158

  -- Looks like a reference, but probably isn't: '5' on line 476

  -- Looks like a reference, but probably isn't: '7' on line 480

  -- Looks like a reference, but probably isn't: '8' on line 483

  -- Looks like a reference, but probably isn't: '9' on line 279

  -- Looks like a reference, but probably isn't: '10' on line 329

  -- Looks like a reference, but probably isn't: '1' on line 470

  -- Looks like a reference, but probably isn't: '2' on line 472

  -- Looks like a reference, but probably isn't: '6' on line 478

  == Outdated reference: A later version (-12) exists of
     draft-cavage-http-signatures-07

  == Outdated reference: A later version (-06) exists of
     draft-ietf-httpbis-origin-frame-04

  == Outdated reference: A later version (-28) exists of
     draft-ietf-tls-tls13-21

  -- Obsolete informational reference (is this intentional?): RFC 7232
     (Obsoleted by RFC 9110)

  -- Obsolete informational reference (is this intentional?): RFC 7234
     (Obsoleted by RFC 9111)

  -- Obsolete informational reference (is this intentional?): RFC 7540
     (Obsoleted by RFC 9113)


     Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------


2	http                                                          J. Yasskin
3	Internet-Draft                                                    Google
4	Intended status: Standards Track                         August 31, 2017
5	Expires: March 4, 2018

7	                      Origin-signed HTTP Responses
8	             draft-yasskin-http-origin-signed-responses-00

10	Abstract

12	   This document explores how a server can send particular responses
13	   that are authoritative for an origin, when the server itself is not
14	   authoritative for that origin.  For now, it focuses on the
15	   constraints covering any such mechanism.

17	Note to Readers

19	   Discussion of this draft takes place on the HTTP working group
20	   mailing list (ietf-http-wg@w3.org), which is archived at
21	   https://lists.w3.org/Archives/Public/ietf-http-wg/.

23	   The source code and issues list for this draft can be found in
24	   https://github.com/WICG/webpackage.

26	Status of This Memo

28	   This Internet-Draft is submitted in full conformance with the
29	   provisions of BCP 78 and BCP 79.

31	   Internet-Drafts are working documents of the Internet Engineering
32	   Task Force (IETF).  Note that other groups may also distribute
33	   working documents as Internet-Drafts.  The list of current Internet-
34	   Drafts is at http://datatracker.ietf.org/drafts/current/.

36	   Internet-Drafts are draft documents valid for a maximum of six months
37	   and may be updated, replaced, or obsoleted by other documents at any
38	   time.  It is inappropriate to use Internet-Drafts as reference
39	   material or to cite them other than as "work in progress."

41	   This Internet-Draft will expire on March 4, 2018.

43	Copyright Notice

45	   Copyright (c) 2017 IETF Trust and the persons identified as the
46	   document authors.  All rights reserved.

48	   This document is subject to BCP 78 and the IETF Trust's Legal
49	   Provisions Relating to IETF Documents
50	   (http://trustee.ietf.org/license-info) in effect on the date of
51	   publication of this document.  Please review these documents
52	   carefully, as they describe your rights and restrictions with respect
53	   to this document.  Code Components extracted from this document must
54	   include Simplified BSD License text as described in Section 4.e of
55	   the Trust Legal Provisions and are provided without warranty as
56	   described in the Simplified BSD License.

58	Table of Contents

60	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
61	   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
62	   3.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
63	     3.1.  PUSHed subresources . . . . . . . . . . . . . . . . . . .   3
64	     3.2.  Explicit use of a CDN for subresources  . . . . . . . . .   3
65	     3.3.  Subresource Integrity . . . . . . . . . . . . . . . . . .   4
66	     3.4.  Offline websites  . . . . . . . . . . . . . . . . . . . .   4
67	   4.  Requirements and open questions . . . . . . . . . . . . . . .   5
68	     4.1.  Proof of origin . . . . . . . . . . . . . . . . . . . . .   5
69	       4.1.1.  The certificate and its chain . . . . . . . . . . . .   5
70	     4.2.  How much to sign  . . . . . . . . . . . . . . . . . . . .   5
71	     4.3.  Response lifespan . . . . . . . . . . . . . . . . . . . .   6
72	       4.3.1.  Certificate revocation  . . . . . . . . . . . . . . .   6
73	       4.3.2.  Response downgrade attacks  . . . . . . . . . . . . .   7
74	     4.4.  Conveying the signed headers  . . . . . . . . . . . . . .   7
75	   5.  Straw proposal  . . . . . . . . . . . . . . . . . . . . . . .   8
76	   6.  Security considerations . . . . . . . . . . . . . . . . . . .   8
77	   7.  Privacy considerations  . . . . . . . . . . . . . . . . . . .   8
78	   8.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   9
79	   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
80	     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
81	     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
82	     9.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
83	   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  11
84	   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

86	1.  Introduction

88	   When I presented Web Packaging to DISPATCH [3], folks thought it
89	   would make sense to split it into a way to sign individual HTTP
90	   responses as coming from a particular origin, and separately a way to
91	   bundle a collection of HTTP responses.  This document explores the
92	   constraints on any method of signing HTTP responses and briefly
93	   sketches a possible solution to the constraints.

95	2.  Terminology

97	   Author  The entity that controls the server for a particular origin
98	      [RFC6454].  The author can get a CA to issue certificates for
99	      their private keys and can run a TLS server for their origin.

101	   Intermediate  An entity that fetches signed HTTP responses from an
102	      author or another intermediate and forwards them to another
103	      intermediate or a client.

105	   Client  An entity that uses a signed HTTP response and needs to be
106	      able to prove that the author vouched for it as coming from its
107	      claimed origin.

109	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
110	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
111	   "OPTIONAL" in this document are to be interpreted as described in BCP
112	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
113	   capitals, as shown here.

115	3.  Use cases

117	3.1.  PUSHed subresources

119	   To reduce round trips, a server might use HTTP/2 PUSH to inject a
120	   subresource from another server into the client's cache.  If anything
121	   about the subresource is expired or can't be verified, the client
122	   would fetch it from the original server.

124	   For example, if "https://example.com/index.html" includes

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

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

132	3.2.  Explicit use of a CDN for subresources

134	   In order to speed up loading but still maintain control over its
135	   content, an HTML page in a particular origin "O.com" could tell
136	   clients to load its subresources from an intermediate CDN that's not
137	   authoritative, but require that those resources be signed by "O.com"
138	   so that the CDN couldn't modify the resources.

140	   <img logicalsrc="https://O.com/img.png"
141	        physicalsrc="https://cdn.com/O.com/img.png">

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

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

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

153	   This could be used for some of the same purposes as SRI
154	   (Section 3.3).

156	3.3.  Subresource Integrity

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

162	   However, their needs also differ in some significant ways:

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

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

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

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

181	3.4.  Offline websites

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

187	4.  Requirements and open questions

189	4.1.  Proof of origin

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

197	   We'll improve adoption if we can re-use existing TLS server
198	   certificates, but if the risks of doing that are too high, we could
199	   define a new Extended Key Usage ([RFC5280], section 4.2.1.12) that
200	   requires CAs to issue new keys for this purpose.  The rest of this
201	   document will assume we can re-use existing TLS server certificates.

203	   It's essential that an attacker who can convince the server to sign
204	   some resource, cannot cause those signed bytes to be interpreted as
205	   something else.  As a result, signatures here need to use the same
206	   format as TLS's signatures, specified in [I-D.ietf-tls-tls13] section
207	   4.4.3, with a context string that's specific to this use.

209	4.1.1.  The certificate and its chain

211	   The client needs to be able to find the certificate vouching for the
212	   signing key and a chain from that certificate to a trusted root.  One
213	   approach would be to include the certificate and its chain in the
214	   signature metadata itself, but this wastes bytes when the same
215	   certificate is used for multiple HTTP responses.  If we decide to put
216	   the signature in an HTTP header, certificates are also unusually
217	   large for that context.

219	   Another option is to pass a URL that the client can fetch to retrieve
220	   the certificate and chain.  To avoid extra round trips in fetching
221	   that URL, it could be bundled (Section 3.4) with the signed content
222	   or PUSHed (Section 3.1) with it.

224	4.2.  How much to sign

226	   The previous [I-D.thomson-http-content-signature] and
227	   [I-D.burke-content-signature] schemes signed just the content, while
228	   ([I-D.cavage-http-signatures] could also sign the response headers
229	   and the request method and path.  However, the same path, response
230	   headers, and content may mean something very different when retrieved
231	   from a different server, so this document expects to include the
232	   whole URL in the signed data as well.

234	   The question of whether to include other request headers--primarily
235	   the "accept*" family--is still open.  These headers need to be
236	   represented so that clients wanting a different language, say, can
237	   avoid using the wrong-language response, but it's not obvious that
238	   there's a security vulnerability if an attacker can spoof them.  That
239	   said, it's always safer to include everything in the signature.

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

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

248	   Instead, it would probably include just

250	   accept-language: ja-JP, ja

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

255	   The rest of this document will assume that all request headers are
256	   included in the signature.

258	4.3.  Response lifespan

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

267	4.3.1.  Certificate revocation

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

275	   Pushed revocation lists work as-is to block trust in the certificate
276	   signing a response, but the signatures need an explicit strategy to
277	   staple OCSP responses.  One option is to extend the certificate
278	   download (Section 4.1.1) to include the OCSP response too, perhaps in
279	   the TLS 1.3 CertificateEntry [9] format.

281	4.3.2.  Response downgrade attacks

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

291	   These assertions could be structured as:

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

298	   2.  A replacement for the whole response's signature.  This requires
299	       the author to separately re-sign each valid version and requires
300	       each version to include a strong validator [RFC7232], but allows
301	       intermediates to serve less data.

303	   3.  A replacement for the response's signature and an update for the
304	       embedded "expires" and related cache-control HTTP headers
305	       [RFC7234].  This naturally extends authors' intuitions about
306	       cache expiration and the existing cache revalidation behavior to
307	       signed responses.  However, it also requires that the update
308	       procedure for the response headers on the client must produce
309	       something that's bytewise identical to the updated headers on the
310	       server.

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

315	4.4.  Conveying the signed headers

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

324	   Since proxies don't modify unknown content types, I expect to propose
325	   an "application/http2" format to serialize the request headers,
326	   response headers, and body so they can be signed.  This could be as
327	   simple as a series of HTTP/2 frames, or could
328	   1.  Allow longer contiguous bodies than HTTP/2's 16MB frame limit
329	       [10], and

331	   2.  Use better compression than [RFC7541] for the non-confidential
332	       headers.

334	   To help the PUSHed subresources use case (Section 3.1), we might also
335	   want to extend the "PUSH_PROMISE" frame type to include a signature,
336	   and then there might be some way to include the request headers
337	   directly in that frame.

339	5.  Straw proposal

341	   TBD

343	6.  Security considerations

345	   Authors MUST NOT include confidential information in a signed
346	   response that an untrusted intermediate could forward, since the
347	   response is only signed and not encrypted.  Intermediates can read
348	   the content.

350	   Relaxing the requirement to consult DNS when determining authority
351	   for an origin means that an attacker who possesses a valid
352	   certificate no longer needs to be on-path to redirect traffic to
353	   them; instead of modifying DNS, they need only convince the user to
354	   visit another Web site in order to serve responses signed as the
355	   target.  This consideration and mitigations for it are shared by
356	   [I-D.ietf-httpbis-origin-frame].

358	   Signing a bad response can affect more users than simply serving a
359	   bad response, since a served response will only affect users who make
360	   a request while the bad version is live, while an attacker can
361	   forward a signed response until its signature expires.  Authors
362	   should consider shorter signature expiration times than they use for
363	   cache expiration times.

365	7.  Privacy considerations

367	   Normally, when a client fetches "https://o1.com/resource.js",
368	   "o1.com" learns that the client is interested in the resource.  If
369	   "o1.com" signs "resource.js", "o2.com" serves it as "https://o2.com/
370	   o1resource.js", and the client fetches it from there, then "o2.com"
371	   learns that the client is interested, and if the client executes the
372	   Javascript, that could also report the client's interest back to
373	   "o1.com".

375	   Often, "o2.com" already knew about the client's interest, because
376	   it's the entity that directed the client to "o1resource.js", but
377	   there may be cases where this leaks extra information.

379	   For non-executable resource types, a signed response can improve the
380	   privacy situation by hiding the client's interest from the original
381	   author.

383	8.  IANA considerations

385	   This document has no actions for IANA.

387	9.  References

389	9.1.  Normative References

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

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

400	9.2.  Informative References

402	   [I-D.burke-content-signature]
403	              Burke, B., "HTTP Header for digital signatures", draft-
404	              burke-content-signature-00 (work in progress), March 2011.

406	   [I-D.cavage-http-signatures]
407	              Cavage, M. and M. Sporny, "Signing HTTP Messages", draft-
408	              cavage-http-signatures-07 (work in progress), July 2017.

410	   [I-D.ietf-httpbis-origin-frame]
411	              Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
412	              draft-ietf-httpbis-origin-frame-04 (work in progress),
413	              August 2017.

415	   [I-D.ietf-tls-tls13]
416	              Rescorla, E., "The Transport Layer Security (TLS) Protocol
417	              Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
418	              July 2017.

420	   [I-D.thomson-http-content-signature]
421	              Thomson, M., "Content-Signature Header Field for HTTP",
422	              draft-thomson-http-content-signature-00 (work in
423	              progress), July 2015.

425	   [I-D.yasskin-dispatch-web-packaging]
426	              Yasskin, J., "Web Packaging", draft-yasskin-dispatch-web-
427	              packaging-00 (work in progress), June 2017.

429	   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
430	              Housley, R., and W. Polk, "Internet X.509 Public Key
431	              Infrastructure Certificate and Certificate Revocation List
432	              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
433	              <https://www.rfc-editor.org/info/rfc5280>.

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

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

444	   [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
445	              Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
446	              DOI 10.17487/RFC7232, June 2014, <https://www.rfc-
447	              editor.org/info/rfc7232>.

449	   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
450	              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
451	              RFC 7234, DOI 10.17487/RFC7234, June 2014,
452	              <https://www.rfc-editor.org/info/rfc7234>.

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

459	   [RFC7541]  Peon, R. and H. Ruellan, "HPACK: Header Compression for
460	              HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
461	              <https://www.rfc-editor.org/info/rfc7541>.

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

468	9.3.  URIs

470	   [1] https://datatracker.ietf.org/doc/minutes-99-dispatch/

472	   [2] https://github.com/mikewest/signature-based-sri

474	   [3] https://github.com/mikewest/signature-based-sri/issues/5

476	   [5] https://tools.ietf.org/html/rfc7540#section-8.2

478	   [6] https://www.imperialviolet.org/2012/02/05/crlsets.html

480	   [7] https://tlswg.github.io/tls13-spec/draft-ietf-tls-
481	       tls13.html#ocsp-and-sct

483	   [8] https://tools.ietf.org/html/rfc7540#section-4.2

485	Appendix A.  Acknowledgements

487	Author's Address

489	   Jeffrey Yasskin
490	   Google

492	   Email: jyasskin@chromium.org