Re: [XHR] chunked requests
On Sat, Dec 10, 2011 at 2:14 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 08 Dec 2011 23:16:37 +0100, Jonas Sicking jo...@sicking.cc wrote: I think Microsoft's stream proposal would address this use case. So that would be: http://html5labs.interoperabilitybridges.com/streamsapi/ How does that relate to the various APIs for streaming media? They're entirely unrelated (except for an unfortunate naming similarity). Microsoft's Streams are a very different abstraction to MediaStreams. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [XHR] chunked requests
On Sun, 18 Dec 2011 13:12:57 +0100, Eric Rescorla e...@rtfm.com wrote: Sorry, I forgot to mention the 1/n+1 splitting countermeasure in my response. With that said, this isn't TLS 1.1, but rather a specific, more backwards-compatible countermeasure. It's fine for the security considerations section to say here that browsers must do either TLS 1.1 or 1/n+1 splitting, but it should say something, since it's not like 1/n+1 splitting is required by TLS (any version). Who's in charge of updating TLS? Surely this should be patched in the base specification rather than in every API that interacts with it. I do not want to make the life of the guy implementing XMLHttpRequest more difficult if the problem is supposed to be addressed at the TLS layer anyway. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] chunked requests
On Tue, Dec 20, 2011 at 9:36 AM, Anne van Kesteren ann...@opera.com wrote: On Sun, 18 Dec 2011 13:12:57 +0100, Eric Rescorla e...@rtfm.com wrote: Sorry, I forgot to mention the 1/n+1 splitting countermeasure in my response. With that said, this isn't TLS 1.1, but rather a specific, more backwards-compatible countermeasure. It's fine for the security considerations section to say here that browsers must do either TLS 1.1 or 1/n+1 splitting, but it should say something, since it's not like 1/n+1 splitting is required by TLS (any version). Who's in charge of updating TLS? Me. Surely this should be patched in the base specification rather than in every API that interacts with it. I do not want to make the life of the guy implementing XMLHttpRequest more difficult if the problem is supposed to be addressed at the TLS layer anyway. The problem was addressed at the TLS layer 5 years ago when we issued TLS 1.1. -Ekr
Re: [XHR] chunked requests
On Tue, 20 Dec 2011 21:06:28 +0100, Eric Rescorla e...@rtfm.com wrote: On Tue, Dec 20, 2011 at 9:36 AM, Anne van Kesteren ann...@opera.com wrote: Surely this should be patched in the base specification rather than in every API that interacts with it. I do not want to make the life of the guy implementing XMLHttpRequest more difficult if the problem is supposed to be addressed at the TLS layer anyway. The problem was addressed at the TLS layer 5 years ago when we issued TLS 1.1. If support for the old version cannot be removed it does not seem to me that the problem is actually addressed as far as user agents that have to support legacy servers are concerned. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] chunked requests
On Tue, Dec 20, 2011 at 12:11 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 20 Dec 2011 21:06:28 +0100, Eric Rescorla e...@rtfm.com wrote: On Tue, Dec 20, 2011 at 9:36 AM, Anne van Kesteren ann...@opera.com wrote: Surely this should be patched in the base specification rather than in every API that interacts with it. I do not want to make the life of the guy implementing XMLHttpRequest more difficult if the problem is supposed to be addressed at the TLS layer anyway. The problem was addressed at the TLS layer 5 years ago when we issued TLS 1.1. If support for the old version cannot be removed it does not seem to me that the problem is actually addressed as far as user agents that have to support legacy servers are concerned. I see your point, but it's not clear what you would like done about it. The TLS WG specifies protocols, not APIs, and this is an API issue. Even if it were within scope, all we would do is add some sort of security considerations note to the TLS spec, but again, it would only apply to RFC 2246, since TLS 1.1 and 1.2 don't have this problem. That isn't to say that the browser stacks aren't adding 1/n+1 splitting. NSS, for instance, has such a fix. However, I don't think there's anything to do from a TLS standards perspective. -Ekr
Re: [XHR] chunked requests
On Tue, 20 Dec 2011 22:55:40 +0100, Eric Rescorla e...@rtfm.com wrote: That isn't to say that the browser stacks aren't adding 1/n+1 splitting. NSS, for instance, has such a fix. However, I don't think there's anything to do from a TLS standards perspective. What I would like is a standard that actually defines what of TLS user agents need to implement. Instead of every user agent having to figure that out for themselves. Those unknowns (TLS is not alone here) create a barrier to entry and make it harder to create user agents that interoperate with legacy content. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] chunked requests
On Tue, Dec 20, 2011 at 2:47 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 20 Dec 2011 22:55:40 +0100, Eric Rescorla e...@rtfm.com wrote: That isn't to say that the browser stacks aren't adding 1/n+1 splitting. NSS, for instance, has such a fix. However, I don't think there's anything to do from a TLS standards perspective. What I would like is a standard that actually defines what of TLS user agents need to implement. Instead of every user agent having to figure that out for themselves. Those unknowns (TLS is not alone here) create a barrier to entry and make it harder to create user agents that interoperate with legacy content. Again, the TLS spec does tell you what to do: it tells you to implement TLS 1.1 and/or 1.2. What you're asking for is for it *also* to tell you what to do in cases where you choose to use a downrev version of TLS. But unfortunately, that guidance is necessarily application specific. In particular, the use of 1/n+1 splitting is the result of discovering that some HTTP stacks don't properly handle empty TLS records and even then some stacks choke Moreover, many non-HTTPS stacks have no need to do any sort of countermeasure because Rizzo-Duong-style attacks don't apply. If/when IETF publishes a revision of TLS, I suspect we'll add a description of 1/n+1 splitting as a backward compatibility measure, but I don't really think it's the role of standards to document security hacks for downrev versions in perpetuity. -Ekr
Re: [XHR] chunked requests
On Sat, Dec 17, 2011 at 6:11 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 09 Dec 2011 19:54:31 +0100, Eric Rescorla e...@rtfm.com wrote: Unfortunately, many servers do not support TLS 1.1, and to make matters worse, they do so in a way that is not securely verifiable. By which I mean that an active attacker can force a client/server pair both of which support TLS 1.1 down to TLS 1.0. This may be detectable in some way, but not by TLS's built-in mechanisms. And since the threat model here is an active attacker, this is a problem. It seems user agents are addressing this issue in general by simply removing support for those servers so we might not have to define anything here and just leave it to the TLS standards: http://my.opera.com/securitygroup/blog/2011/12/11/opera-11-60-and-new-problems-with-some-secure-servers Sorry, I forgot to mention the 1/n+1 splitting countermeasure in my response. With that said, this isn't TLS 1.1, but rather a specific, more backwards-compatible countermeasure. It's fine for the security considerations section to say here that browsers must do either TLS 1.1 or 1/n+1 splitting, but it should say something, since it's not like 1/n+1 splitting is required by TLS (any version). -Ekr
Re: [XHR] chunked requests
On Fri, 09 Dec 2011 19:54:31 +0100, Eric Rescorla e...@rtfm.com wrote: Unfortunately, many servers do not support TLS 1.1, and to make matters worse, they do so in a way that is not securely verifiable. By which I mean that an active attacker can force a client/server pair both of which support TLS 1.1 down to TLS 1.0. This may be detectable in some way, but not by TLS's built-in mechanisms. And since the threat model here is an active attacker, this is a problem. It seems user agents are addressing this issue in general by simply removing support for those servers so we might not have to define anything here and just leave it to the TLS standards: http://my.opera.com/securitygroup/blog/2011/12/11/opera-11-60-and-new-problems-with-some-secure-servers -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] chunked requests
On Sat, Dec 17, 2011 at 6:11 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 09 Dec 2011 19:54:31 +0100, Eric Rescorla e...@rtfm.com wrote: Unfortunately, many servers do not support TLS 1.1, and to make matters worse, they do so in a way that is not securely verifiable. By which I mean that an active attacker can force a client/server pair both of which support TLS 1.1 down to TLS 1.0. This may be detectable in some way, but not by TLS's built-in mechanisms. And since the threat model here is an active attacker, this is a problem. It seems user agents are addressing this issue in general by simply removing support for those servers so we might not have to define anything here and just leave it to the TLS standards: http://my.opera.com/securitygroup/blog/2011/12/11/opera-11-60-and-new-problems-with-some-secure-servers I would still add a security consideration so folks who implement this are aware that the two issues are related. Adam
RE: [XHR] chunked requests
We've only recently uploaded the draft for the Streams API and shared it with the Working Group [1], which also has the new location. There is a conversation currently taking place in the media capture WG [2] discussing how to better align Stream and MediaStream. I think it's an interesting topic worth investigating, and there are a few ideas that have been proposed. We'll have to see where the conversation lands. Thanks, Feras [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1494.html [2] http://lists.w3.org/Archives/Public/public-media-capture/2011Dec/0037.html -Original Message- From: Anne van Kesteren [mailto:ann...@opera.com] Sent: Friday, December 09, 2011 5:15 AM To: Wenbo Zhu; Jonas Sicking; Robert O'Callahan; Feras Moussa Cc: WebApps WG Subject: Re: [XHR] chunked requests On Thu, 08 Dec 2011 23:16:37 +0100, Jonas Sicking jo...@sicking.cc wrote: I think Microsoft's stream proposal would address this use case. So that would be: http://html5labs.interoperabilitybridges.com/streamsapi/ How does that relate to the various APIs for streaming media? (I added roc and Feras Moussa.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] chunked requests
On Wed, 14 Dec 2011 20:17:01 +0100, Feras Moussa fer...@microsoft.com wrote: We've only recently uploaded the draft for the Streams API and shared it with the Working Group [1], which also has the new location. There is a conversation currently taking place in the media capture WG [2] discussing how to better align Stream and MediaStream. I think it's an interesting topic worth investigating, and there are a few ideas that have been proposed. We'll have to see where the conversation lands. Cool! Let me know when I should start adding the relevant text to XMLHttpRequest. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] chunked requests
On Thu, Dec 8, 2011 at 2:36 PM, Charles Pritchard ch...@jumis.com wrote: On Dec 8, 2011, at 1:04 PM, Wenbo Zhu wen...@google.com wrote: On Wed, Dec 7, 2011 at 6:04 PM, Charles Pritchard ch...@jumis.com ch...@jumis.com wrote: ** I think the Web Sockets spec is intended for client to server sessions like this. WebSocket protocol isn't yet well-supported by proxies. Besides, all we need here is a throwaway RPC-like request/response, and it's a bit heavy duty to use WebSocket for this use case. Isn't a chunked stream the anti-thesis of RPC? Streaming request or response does not imply bi-directional messaging, i.e. the (non-RPC) semantics of WebSocket. It looks like you're acknowledging WebSockets works while asking about what to do with current web infrastructure. It seems to me that current infrastructure is -mostly- Flash based and assumes a level of control over input: one can't send arbitrary information as a developer.. It has to be directly from a webcam or similar media stream. Do you have specific examples of existing infrastructure you're hoping to support? See below. As for the peer-to-peer communication, I imagine the WebRTC group is where you'll see more activity on this issue. WebRTC is mostly peer-to-peer UDP (e.g. RTP), and the client-to-client communication has nothing to do with either HTTP or WebSocket. And MediaStream/Stream, which has to so with your request. Not sure about the status of this spec. My original email merely tries to show the need to process/post data locally ... http://developers.whatwg.org/video-conferencing-and-peer-to-peer-communication.html#video-conferencing-and-peer-to-peer-communication I don't know that arbitrary binary data is on their agenda -- I hope it is -- for p2p communication. On 12/7/11 5:59 PM, Wenbo Zhu wrote: One use case that we have which is not currently handled by XMLHttpRequest is incrementally sending data that takes a long time to generate _from the client to the server_. For example, if we were to record data from a microphone, we couldn't upload it in real time to the server with the current API. The MediaStreaming spec also mentioned several use cases which would require streaming request data via an API: - Sending the locally-produced streams to remote peers and receiving streams from remote peers. - Sending arbitrary data to remote peers. http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html - Wenbo
Re: [XHR] chunked requests
On Fri, 09 Dec 2011 02:13:50 +0100, Eric Rescorla e...@rtfm.com wrote: On Thu, Dec 8, 2011 at 5:07 PM, Adam Barth w...@adambarth.com wrote: Whatever spec we end up going with should note in its security consideration that the user agent must implement TLS 1.2 or greater to avoid this attack. I believe it's actually TLS 1.1, since the relevant feature is explicit IVs. Or you could allow RC4, I guess. Are you saying that if responseType is set to stream and the server only supports TLS 1.0 the connection should fail, but if it is greater than that it is okay? Same-origin requests are always okay? (Though it seems we should just require TLS 1.1 there too then to not make matters too confusing.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] chunked requests
On Thu, 08 Dec 2011 23:16:37 +0100, Jonas Sicking jo...@sicking.cc wrote: I think Microsoft's stream proposal would address this use case. So that would be: http://html5labs.interoperabilitybridges.com/streamsapi/ How does that relate to the various APIs for streaming media? (I added roc and Feras Moussa.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] chunked requests
On Fri, Dec 9, 2011 at 4:59 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 09 Dec 2011 02:13:50 +0100, Eric Rescorla e...@rtfm.com wrote: On Thu, Dec 8, 2011 at 5:07 PM, Adam Barth w...@adambarth.com wrote: Whatever spec we end up going with should note in its security consideration that the user agent must implement TLS 1.2 or greater to avoid this attack. I believe it's actually TLS 1.1, since the relevant feature is explicit IVs. Or you could allow RC4, I guess. Are you saying that if responseType is set to stream and the server only supports TLS 1.0 the connection should fail, but if it is greater than that it is okay? I'm not sure I understand this feature well enough. The issue is streaming content from the client, not from the server, and in particular the ability of the JS to provide additional content to be sent after the data has started to be transmitted. As for what should happen in this setting if the negotiated TLS version is 1.0, I could imagine a number of possibilities, including: 1. The client refuses to send 2. There is a pre-flight and the server has to explicitly accept. 3. There is a big nasty warning. 4. We just warn people in the spec and hope they do something sensible Same-origin requests are always okay? (Though it seems we should just require TLS 1.1 there too then to not make matters too confusing.) Same-origin requests should be OK because the JS would have access to the relevant sensitive data in any case. -Ekr
Re: [XHR] chunked requests
On Fri, 09 Dec 2011 16:33:08 +0100, Eric Rescorla e...@rtfm.com wrote: On Fri, Dec 9, 2011 at 4:59 AM, Anne van Kesteren ann...@opera.com wrote: Are you saying that if responseType is set to stream and the server only supports TLS 1.0 the connection should fail, but if it is greater than that it is okay? I'm not sure I understand this feature well enough. The issue is streaming content from the client, not from the server, and in particular the ability of the JS to provide additional content to be sent after the data has started to be transmitted. My bad. I meant send(Stream) which would indeed allow for that. As for what should happen in this setting if the negotiated TLS version is 1.0, I could imagine a number of possibilities, including: 1. The client refuses to send 2. There is a pre-flight and the server has to explicitly accept. 3. There is a big nasty warning. 4. We just warn people in the spec and hope they do something sensible Okay. I think I would very much prefer 1 here. Same-origin requests are always okay? (Though it seems we should just require TLS 1.1 there too then to not make matters too confusing.) Same-origin requests should be OK because the JS would have access to the relevant sensitive data in any case. Okay, I guess we can make that difference. Thanks, -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] chunked requests
On Fri, Dec 9, 2011 at 7:59 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 09 Dec 2011 16:33:08 +0100, Eric Rescorla e...@rtfm.com wrote: On Fri, Dec 9, 2011 at 4:59 AM, Anne van Kesteren ann...@opera.com wrote: Are you saying that if responseType is set to stream and the server only supports TLS 1.0 the connection should fail, but if it is greater than that it is okay? I'm not sure I understand this feature well enough. The issue is streaming content from the client, not from the server, and in particular the ability of the JS to provide additional content to be sent after the data has started to be transmitted. My bad. I meant send(Stream) which would indeed allow for that. As for what should happen in this setting if the negotiated TLS version is 1.0, I could imagine a number of possibilities, including: 1. The client refuses to send 2. There is a pre-flight and the server has to explicitly accept. 3. There is a big nasty warning. 4. We just warn people in the spec and hope they do something sensible Okay. I think I would very much prefer 1 here. Same-origin requests are always okay? (Though it seems we should just require TLS 1.1 there too then to not make matters too confusing.) Same-origin requests should be OK because the JS would have access to the relevant sensitive data in any case. Okay, I guess we can make that difference. Correct me if I'm wrong, but I believe these issues are fixed in TLS 1.1. Most user agents implement TLS 1.1 anyway, so this seems mostly like a requirement to put in the security considerations section. Adam
Re: [XHR] chunked requests
On Fri, Dec 9, 2011 at 10:37 AM, Adam Barth w...@adambarth.com wrote: On Fri, Dec 9, 2011 at 7:59 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 09 Dec 2011 16:33:08 +0100, Eric Rescorla e...@rtfm.com wrote: Same-origin requests should be OK because the JS would have access to the relevant sensitive data in any case. Okay, I guess we can make that difference. Correct me if I'm wrong, but I believe these issues are fixed in TLS 1.1. Most user agents implement TLS 1.1 anyway, so this seems mostly like a requirement to put in the security considerations section. Would that it were this easy. Unfortunately, many servers do not support TLS 1.1, and to make matters worse, they do so in a way that is not securely verifiable. By which I mean that an active attacker can force a client/server pair both of which support TLS 1.1 down to TLS 1.0. This may be detectable in some way, but not by TLS's built-in mechanisms. And since the threat model here is an active attacker, this is a problem. -Ekr
Re: [XHR] chunked requests
On Dec 8, 2011, at 1:04 PM, Wenbo Zhu wen...@google.com wrote: On Wed, Dec 7, 2011 at 6:04 PM, Charles Pritchard ch...@jumis.com wrote: I think the Web Sockets spec is intended for client to server sessions like this. WebSocket protocol isn't yet well-supported by proxies. Besides, all we need here is a throwaway RPC-like request/response, and it's a bit heavy duty to use WebSocket for this use case. Isn't a chunked stream the anti-thesis of RPC? It looks like you're acknowledging WebSockets works while asking about what to do with current web infrastructure. It seems to me that current infrastructure is -mostly- Flash based and assumes a level of control over input: one can't send arbitrary information as a developer.. It has to be directly from a webcam or similar media stream. Do you have specific examples of existing infrastructure you're hoping to support? As for the peer-to-peer communication, I imagine the WebRTC group is where you'll see more activity on this issue. WebRTC is mostly peer-to-peer UDP (e.g. RTP), and the client-to-client communication has nothing to do with either HTTP or WebSocket. And MediaStream/Stream, which has to so with your request. I don't know that arbitrary binary data is on their agenda -- I hope it is -- for p2p communication. On 12/7/11 5:59 PM, Wenbo Zhu wrote: One use case that we have which is not currently handled by XMLHttpRequest is incrementally sending data that takes a long time to generate _from the client to the server_. For example, if we were to record data from a microphone, we couldn't upload it in real time to the server with the current API. The MediaStreaming spec also mentioned several use cases which would require streaming request data via an API: - Sending the locally-produced streams to remote peers and receiving streams from remote peers. - Sending arbitrary data to remote peers. http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html - Wenbo
Re: [XHR] chunked requests
Keep in mind that streamed or chunked uploads will expose the ability to exploit the BEAST vulnerability in SSL: http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html Whatever spec we end up going with should note in its security consideration that the user agent must implement TLS 1.2 or greater to avoid this attack. Adam On Thu, Dec 8, 2011 at 2:16 PM, Jonas Sicking jo...@sicking.cc wrote: I think Microsoft's stream proposal would address this use case. / Jonas On Wed, Dec 7, 2011 at 5:59 PM, Wenbo Zhu wen...@google.com wrote: One use case that we have which is not currently handled by XMLHttpRequest is incrementally sending data that takes a long time to generate _from the client to the server_. For example, if we were to record data from a microphone, we couldn't upload it in real time to the server with the current API. The MediaStreaming spec also mentioned several use cases which would require streaming request data via an API: - Sending the locally-produced streams to remote peers and receiving streams from remote peers. - Sending arbitrary data to remote peers. http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html - Wenbo
Re: [XHR] chunked requests
On Thu, Dec 8, 2011 at 5:07 PM, Adam Barth w...@adambarth.com wrote: Keep in mind that streamed or chunked uploads will expose the ability to exploit the BEAST vulnerability in SSL: http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html Right. Specifically, it needs to be a cross-origin streamed request without significant uncontrollable headers and/or masking. Whatever spec we end up going with should note in its security consideration that the user agent must implement TLS 1.2 or greater to avoid this attack. I believe it's actually TLS 1.1, since the relevant feature is explicit IVs. Or you could allow RC4, I guess. Best, -Ekr
[XHR] chunked requests
One use case that we have which is not currently handled by XMLHttpRequest is incrementally sending data that takes a long time to generate _from the client to the server_. For example, if we were to record data from a microphone, we couldn't upload it in real time to the server with the current API. The MediaStreaming spec also mentioned several use cases which would require streaming request data via an API: - Sending the locally-produced streams to remote peers and receiving streams from remote peers. - Sending arbitrary data to remote peers. http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html - Wenbo
