- From: Brian Raymor <Brian.Raymor@microsoft.com>
- Date: Wed, 31 Aug 2011 19:43:35 +0000
- To: Arthur Barstow <art.barstow@nokia.com>
- CC: ext Adam Barth <w3c@adambarth.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Thomas Roessler <tlr@w3.org>, "Salvatore Loreto" <salvatore.loreto@ericsson.com>, "public-ietf-w3c@w3.org" <public-ietf-w3c@w3.org>, WebApps WG <public-webapps@w3.org>, François Daoust <fd@w3.org>, Eric Rescorla <ekr@rtfm.com>, Harald Alvestrand <harald@alvestrand.no>, Tobias Gondrom <tobias.gondrom@gondrom.org>
Hi Art, I've updated the bug. Microsoft is fine with this new validation requirement. In the absence of other comments, I suggest that we update the draft and move on to Last Call. ...Brian > -----Original Message----- > From: Arthur Barstow [mailto:art.barstow@nokia.com] > Sent: Monday, August 29, 2011 9:30 AM > To: Brian Raymor > Cc: ext Adam Barth; Gabriel Montenegro; Thomas Roessler; Salvatore Loreto; > public-ietf-w3c@w3.org; WebApps WG; François Daoust; Eric Rescorla; Harald > Alvestrand; Tobias Gondrom > Subject: Re: HTTP, websockets, and redirects > > Hi Brian, All - I just checked Bugzilla and besides the two editorial type bugs > (12510 and 13700), bug 13777 was filed against the Web Sockets API on > August 15: > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=13777 > > Currently, there have been no followup comments on 13777 and I think it > should be addressed before the LC is published. > > -Art Barstow > > > On 8/25/11 2:31 PM, ext Brian Raymor wrote: > >> On Wed, Aug 10, 2011 at 9:01 AM, Arthur Barstow< > art.barstow@nokia.com> wrote: > >>> Hi All, > >>> > >>> Bugzilla now reports only 2 bugs for the Web Socket API [WSAPI] and > >>> I would characterize them both as editorial [Bugs]. As such, the > >>> redirect issue Thomas originally reported in this thread (see > >>> [Head]) appears to be the only substantive issue blocking WSAPI Last > Call. > > As Art notes, the remaining bugs for the WebSocket API [WSAPI] can be > characterized as editorial bugs. > > > > Microsoft has no objections to the requirement to fail non-101 responses > such as redirects. If there are no further concerns in the working group > related to this issue, then the current WebSocket API looks feature > complete. I recommend that we publish a Last Call working draft and define a > timetable to reach Candidate Recommendation. > > > >>> If anyone wants to continue discussing this redirect issue for > >>> WSAPI, I recommend using e-mail (additionally, it may be useful to > >>> also create a new bug in Bugzilla). > >>> > >>> As I understand it, the HyBi WG plans to freeze the Web Socket > >>> Protocol spec "real soon now" (~August 19?). > >>> > >>> -Art Barstow > >>> > >>> [WSAPI] http://dev.w3.org/html5/websockets/ > >>> [Head] > >>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0474.h > >>> t > >>> ml > >>> [Bugs] > >>> > http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&shor > >>> t _de > >>> > sc_type=allwordssubstr&short_desc=&product=WebAppsWG&component= > We > >>> > bSocket+API+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubs > tr > >>> bSocket+API+& > >>> > longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whit > >>> e > >>> boar > >>> > d_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&ke > yw > >>> o r > >>> > ds=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&em > ailt > >>> > ype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=any > e > >>> x > >>> > act&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtyp > e= > >>> d > >>> oit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0- > >>> 0=noop&value0-0-0= > >>> > >>> > >>> On 7/27/11 8:12 PM, ext Adam Barth wrote: > >>>> On Mon, Jul 25, 2011 at 3:52 PM, Gabriel Montenegro > >>>> <Gabriel.Montenegro@microsoft.com> wrote: > >>>>> Thanks Adam, > >>>>> > >>>>> By discussed on some mailing list, do you mean a *W3C* mailing list? > >>>> A quick search turned up this message: > >>>> > >>>> "But I'm totally fine with punting on this for the future and just > >>>> disallowing redirects on an API level for now." > >>>> > >>>> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011- > March/031079. > >>>> html > >>>> > >>>> I started that thread at Greg Wilkins' recommendation: > >>>> > >>>> "This is essentially an API issue for the browser websocket object." > >>>> > >>>> http://www.ietf.org/mail-archive/web/hybi/current/msg06954.html > >>>> > >>>>> Also, allowing the users to handle these explicitly implies that > >>>>> the API does > >>> not mandate dropping the connection. Currently, the API does not > >>> have this flexibility, nor does it allow other uses of non-101 > >>> codes, like for authentication. I understand the potential risks > >>> with redirects in browsers, and I thought at one moment we were > >>> going to augment the security considerations with your help for > >>> additional guidance. If websec has already worked on similar > >>> language in some draft that we could reuse that would be great, or, > similarly, if we could work with you on that text. > >>>> We can always add support for explicitly following redirects in the > >>>> future. If we were to automatically follow them today, we'd never > >>>> be able to remove that behavior by default. > >>>> > >>>> Adam > >>>> > >>>> > >>>>>> -----Original Message----- > >>>>>> From: Adam Barth [mailto:w3c@adambarth.com] > >>>>>> Sent: Sunday, July 24, 2011 13:35 > >>>>>> To: Thomas Roessler > >>>>>> Cc: public-ietf-w3c@w3.org; WebApps WG; Salvatore Loreto; Gabriel > >>>>>> Montenegro; Art Barstow; François Daoust; Eric Rescorla; Harald > >>>>>> Alvestrand; Tobias Gondrom > >>>>>> Subject: Re: HTTP, websockets, and redirects > >>>>>> > >>>>>> This issue was discussed on some mailing list a while back (I > >>>>>> forget which). The consensus seemed to be that redirects are the > >>>>>> source of a large number of security vulnerabilities in HTTP and > >>>>>> we'd like users of the WebSocket API to handle them explicitly. > >>>>>> > >>>>>> I'm not sure I understand your question regarding WebRTC, but the > >>>>>> general answer to that class of questions is that WebRTC relies, > >>>>>> in large part, on ICE to be secure against cross-protocol and > >>>>>> voicehammer > >>> attacks. > >>>>>> Adam > >>>>>> > >>>>>> > >>>>>> On Sun, Jul 24, 2011 at 6:52 AM, Thomas Roessler<tlr@w3.org> > wrote: > >>>>>>> The hybi WG is concerned about the following clause in the > >>>>>>> websocket API > >>>>>> spec: > >>>>>>>> When the user agent validates the server's response during the > >>>>>>>> "establish a > >>>>>> WebSocket connection" algorithm, if the status code received from > >>>>>> the server is not 101 (e.g. it is a redirect), the user agent > >>>>>> must fail the > >>> websocket connection. > >>>>>>> http://dev.w3.org/html5/websockets/ > >>>>>>> > >>>>>>> Discussion with the WG chairs: > >>>>>>> > >>>>>>> - this looks like a conservative attempt to lock down redirects > >>>>>>> in the face of ill-understood cross-protocol interactions > >>>>>>> - critical path for addressing includes analysis of interaction > >>>>>>> with XHR, XHR2, CORS > >>>>>>> - following redirects in HTTP is optional for the client, > >>>>>>> therefore in principle a decision that a client-side spec can > >>>>>>> profile > >>>>>>> - concern about ability to use HTTP fully before 101 succeeds, > >>>>>>> and future extensibility > >>>>>>> > >>>>>>> Salvatore and Gabriel will bring this up later in the week with > >>>>>>> websec, and we'll > >>>>>> probably want to make it a discussion with Webappsec, too. > >>>>>>> Side note: Does WebRTC have related issues concerning multiple > >>>>>>> protocols in a > >>>>>> single-origin context? Are there lessons to learn from them, or > >>>>>> is the case sufficiently different that we need a specific analysis > here? > >>>>>>> Thanks,
Received on Wednesday, 31 August 2011 19:44:07 UTC