On Thu, Feb 17, 2011 at 1:47 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
In this case, we're guaranteed that what comes out is a DNS packet, and it is (presumably, I don't remember if the dns URL allows server specification) sent towards a destination that the OS/browser thinks is a DNS server. So I think of this as "browser-vetted content".
Guaranteed to be a dns packet, but the "authority" section allows you to name where the packet is meant to go. Something similar to a same-origin policy could say "can't name your own authority in a DNS URI", but as far as I know it does not. <snip>
Yup, something similar is contemplated within the Caja effort with regard to passing Javascript resources between contexts running in the same browsers without compromising security. And of course the whole STUN handshake is an example of "pawn ticket" in action (if I understand the term correctly)
I'm thinking of the URLAUTH mechanism described by LEMONADE: http://tools.ietf.org/search/rfc4467 That's a limited-use proof-of-possession model for authorization, with no authentication implied (just as anyone in possession of a pawn ticket can redeem the item out of pawn). STUN is a user-name and password model either long term or short term. The short-term method can use some out-of-band mechanism to assign time-limited username/passwords. I'm still noodling out the pawn-ticket model's applicability here, and some of it depends on the use case at hand. For the "see the faces of the poker players", I can see using something like a limited-use cooking being shared by the players as a nonce for creating the session. In more DTLS terms: Client 1 visits gaming site and gets a token: "32bitF000" when assigned to game 1. Client 2 gets the same token when assigned to game 1. Each uses 32bitF000 as a nonce to replace their address when supplying a client Hello to their peers. The shared token indicates they got it from the same place and intend to be in the same game. Each peer sees the shared token, and uses it to provide a session cookie (since it uses more than the nonce to create the cookie, the peer cannot gen one up on his own). This provides the return routability check. Whenever a player drops out of the game, they drop their recognition of 32bitF00 token, so they will no longer start sessions with anyone presenting that nonce/token. Using a similar idea to replace same-origin in javascript is harder than the dtls example, and I'm still working through in my head whether it will work. regards, Ted
regards,
Ted
So far, we have assumed that the STUN handshake is our defense against the first one, and that it's OK to send out a moderate amount of STUN-formatted UDP packets to ports and IP addresses chosen by the script, believing that the STUN format prevents them from being parsed as valid packets by other protocols.
(Query: What other operations need to be protected against?)
Things that can't be done:
- Anything that requires timing of events within 20-100 ms of each other - Anything that depends on multithreading behaviour in the browser
In both cases, Javascript just doesn't work that way.
I think the TCP constraint + the UDP constraint means that we can't implement SIP or XMPP in Javascript without a gateway that talks SIP-over-HTTP - you just can't get around the security features.
I think the timing constraint means that if you implement ICE in Javascript, you're going to need to have seriously relaxed timing constraints - the standard specifies that you should try candidates at<complicated expression that usually turns out to be 20 ms>.
What else are serious limitations on what we can or cannot do?
What are the consequences?
Harald
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web