- From: Adam Barth <w3c@adambarth.com>
- Date: Fri, 9 Dec 2011 10:37:38 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Eric Rescorla <ekr@rtfm.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 7:59 AM, Anne van Kesteren <annevk@opera.com> wrote: > On Fri, 09 Dec 2011 16:33:08 +0100, Eric Rescorla <ekr@rtfm.com> wrote: >> On Fri, Dec 9, 2011 at 4:59 AM, Anne van Kesteren <annevk@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
Received on Friday, 9 December 2011 18:38:48 UTC