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