Peter Saint-Andre | 18 Jul 21:53 2011

Call for feedback on web origin spec (was: Fwd: [websec] WG Last Call on draft-ietf-websec-origin-02 until Aug-15)

If you have an interest, please review draft-ietf-websec-origin and send 
your feedback to the websec@... list:

https://www.ietf.org/mailman/listinfo/websec

Thanks!

/psa

-------- Original Message --------
Subject: [websec] WG Last Call on draft-ietf-websec-origin-02 until Aug-15
Date: Mon, 18 Jul 2011 20:38:04 +0100
From: Tobias Gondrom <tobias.gondrom@...>
To: websec@...

Hello dear websec fellows,

after reading the feedback and the update on the origin draft, I have
the impression that the draft is in good shape and like to ask for WG
Last Call for this document:
http://tools.ietf.org/html/draft-ietf-websec-origin-02

As we are close to the IETF meeting in Quebec, this last call will be
extended to four weeks and _*close on August-15.*_ Please make a last
careful review of the draft and submit comments, questions and discuss
items for this draft ASAP. If you perceive any major issues, it might
also make sense to raise them during our meeting in Quebec on July-25.

Kind regards and thank you,

(Continue reading)

Peter Saint-Andre | 20 Jul 03:44 2011

Minutes of the W3C/IETF Coordination Call, July 18, 2011

Minutes of the W3C/IETF Coordination Call, July 18, 2011

Attending: Mark Nottingham, Peter Saint-Andre, Pete Resnick, Sean
Turner, Robert Sparks, Gabriel Montenegro, Alissa Cooper, Thomas
Roessler, Brian Raymor, John Klensin, Adrian Bateman

Regrets: Philippe Le Hagaret, Russ Housley, Stephen Farrell

- Action Item Status (for context, see
<http://www.w3.org/mid/4DFB7645.4030301 <at> stpeter.im>)

ACTION: Pete to send notice of RFC3536bis Last Call to the public list,
mailto:public-ietf-w3c <at> w3.org
-- done; document is approved and heading to RFC editor.

ACTION: liaisons on both sides to gather list of current activities /
interests in prep for discussions in Quebec City.

ACTION: Peter to send reminder for feedback about same-origin to
mailto:public-ietf-w3c <at> w3.org
-- WGLC in WEBSEC WG after IETF 81, will send reminder then

ACTION: Mark to follow up on finding a home for John Kemp's work on HTTP
Security.
-- done.

- IETF HYBI / W3C WebSockets API  [ Gabriel / Thomas ]

   - deflate-stream
     - this is a MAY in the spec right now
(Continue reading)

Thomas Roessler | 24 Jul 15:52 2011
Picon

HTTP, websockets, and redirects

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,
--
Thomas Roessler, W3C  <tlr <at> w3.org>  ( <at> roessler)

Adam Barth | 24 Jul 19:35 2011

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 <at> 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
>
(Continue reading)

Gabriel Montenegro | 26 Jul 00:52 2011
Picon

RE: HTTP, websockets, and redirects

Thanks Adam,

By discussed on some  mailing list, do you mean a *W3C* mailing list? 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.

Thanks,

Gabriel

> -----Original Message-----
> From: Adam Barth [mailto:w3c <at> adambarth.com]
> Sent: Sunday, July 24, 2011 13:35
> To: Thomas Roessler
> Cc: public-ietf-w3c <at> 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
(Continue reading)

Adam Barth | 28 Jul 02:12 2011

Re: HTTP, websockets, and redirects

On Mon, Jul 25, 2011 at 3:52 PM, Gabriel Montenegro
<Gabriel.Montenegro <at> 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.

(Continue reading)


Gmane