- From: Eric Rescorla <ekr@rtfm.com>
- Date: Tue, 20 Dec 2011 13:55:40 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: public-webapps@w3.org
On Tue, Dec 20, 2011 at 12:11 PM, Anne van Kesteren <annevk@opera.com> wrote: > On Tue, 20 Dec 2011 21:06:28 +0100, Eric Rescorla <ekr@rtfm.com> wrote: >> >> On Tue, Dec 20, 2011 at 9:36 AM, Anne van Kesteren <annevk@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
Received on Tuesday, 20 December 2011 21:56:57 UTC