Streaming upload and HTTP protocol info leak

[yutakahirano]

At #966 we are talking about restricting the streaming upload feature only for certain HTTP versions (H1.1 and above, or H2 and above).

This may leak protocol versions, so we are wondering if Timing-Allow-Origin is needed.

On the other hand, the feature requires CORS preflight and some resource timing people talked about a possibility that CORS implies TAO.

@yoavweiss @npm1 What do you think?

cc: @sleevi @annevk @yoichio

[npm1]

We have an issue regarding nextHopProtocol: w3c/resource-timing#221. I don't think that right now it's gated under Timing-Allow-Origin, so I see no reason to gate on this here. It's not the correct header to use here, as TAO should affect measurement, not functionality. It would be better to consider whether other security primitives (CORP, COEP) are needed here. TAO is not.

[annevk]

Yeah, when I read the nextHopProtocol description I also immediately thought that it would be an issue for same-origin as well. That's not to say that it's not a problem for cross-origin as well though, but that's a different issue from revealing proxies.

[yutakahirano]

Thank you for the clarification! I changed the issue title.

[yoavweiss]

/cc @camillelamy @mikewest

[yoichio]

I'm considering below API in fetch:

fetch('https://grpc.example.com/posts', {
  method: 'POST',
  body: createReadableStream(content),
  AllowHTTP1ForStreamingUpload: false})
.catch((error) => {
    // This error flag is also a new API.
    // This means middleboxes forced H1 (e.g. a local proxy), 
    // and the author can detect that and fall back to non-streaming upload.
  if (error.IsHTTP1Negotiated) {
   fallbackUploadWithoutStream(content);
  }
});

With that, web author knows the negotiated protocol is HTTP/1.
This can be abused as nextHopProtocol? If so, how might we refrain from it?

[sleevi]

I didn’t think the proposal was for a new error API. Is that actually necessary? PerformanceResourceTiming already provides error surface, doesn’t it? Having an explicit API, especially beyond Network Error, seems like it would require much more careful security review.

[yutakahirano]

@sleevi Is a PerformanceResourceTiming record added for failure cases?

[sleevi]

@sleevi Is a PerformanceResourceTiming record added for failure cases?

https://w3c.github.io/resource-timing/#resources-included-in-the-performanceresourcetiming-interface

Resources for which the fetch was initiated, but was later aborted (e.g. due to a network error) MAY be included as PerformanceResourceTiming objects in the Performance Timeline and MUST contain initialized attribute values for processed substeps of the processing model.

[yutakahirano]

Thank you.

The problematic part is, usually we know the HTTP version when the response arrives, in this case we need to fail the request before sending the request. Also we were talking about rejecting the request when the server likely to use HTTP/0.9 and HTTP/1.0: #966 (comment).

Does the following make sense to you?

1. Same-origin case
   1. If the response to the main resource used HTTP/0.9 or HTTP/1.0:
      Fail the request, and record that HTTP version to the PerformanceResourceTiming entry of the failed request.
   2. If there is an existing HTTP/2 session, or the browser succeeded to create an HTTP/2 session: Continue processing the request.
   3. if AllowHTTP1ForStreamingUpload is true:
      Continue processing the request.
   4. if AllowHTTP1ForStreamingUpload is false:
      Fail the request, and record HTTP/1.1 to the PerformanceResourceTiming entry of the failed request.
2. Cross-origin case
   1. If the response to the CORS preflight used HTTP/0.9 or HTTP/1.0:
      Fail the request, and record that HTTP version to the PerformanceResourceTiming entry of the failed request.
   2. If there is an existing HTTP/2 session, or the browser succeeded to create an HTTP/2 session: Continue processing the request.
   3. if AllowHTTP1ForStreamingUpload is true:
      Continue processing the request.
   4. if AllowHTTP1ForStreamingUpload is false:
      Fail the request, and record HTTP/1.1 to the PerformanceResourceTiming entry of the failed request.

[yoichio]

I think session existence and the flag are independent to each other.
Thus the condition list should look like:

1. If there is an HTTP/2 session,
   1. if AllowHTTP1ForStreamingUpload is true ..
   2. if AllowHTTP1ForStreamingUpload is false ..
2. If there is no HTTP/2 session,
   1. if AllowHTTP1ForStreamingUpload is true ..
   2. if AllowHTTP1ForStreamingUpload is false ..

Also there is no difference between Same-origin and Cross-origin case. Is that true?

[sleevi]

The problematic part is, usually we know the HTTP version when the response arrives, in this case we need to fail the request before sending the request.

I’m not sure I understand? You know the transport protocol before you’ve sent the request. Either:

• You established a TLS connection and no ALPN was negotiated or H1 (1.1/1.0/0.9) was explicitly negotiated
  • Check the flag / Fail the request
• You established a TLS connection and ALPN negotiated H/2
  • You’re talking H/2 and are fine
• You established a QUIC connection and thus negotiated H/3
  • You’re talking H/3 and are fine

The only time you need the response to know the version is when you’re talking <= H/1, but that’s OK, because you already know that by needing that, you’re talking H/1

[yoichio]

Friendly ping @yutakahirano ?