[RTW] Criteria for what one can do in Javascript vs what one has to do inside the browser

[Ted Hardie]

On Thu, Feb 17, 2011 at 1:47 PM, Harald Alvestrand <harald at 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 at alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>>
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>