- From: Eric Rescorla <ekr@rtfm.com>
- Date: Fri, 9 Dec 2011 07:33:08 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Adam Barth <w3c@adambarth.com>, Jonas Sicking <jonas@sicking.cc>, Wenbo Zhu <wenboz@google.com>, public-webapps@w3.org, Ian Hickson <ian@hixie.ch>
On Fri, Dec 9, 2011 at 4:59 AM, Anne van Kesteren <annevk@opera.com> wrote: > On Fri, 09 Dec 2011 02:13:50 +0100, Eric Rescorla <ekr@rtfm.com> wrote: >> >> On Thu, Dec 8, 2011 at 5:07 PM, Adam Barth <w3c@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
Received on Friday, 9 December 2011 15:35:10 UTC