- From: Ted Goddard <ted.goddard@icesoft.com>
- Date: Thu, 27 Oct 2005 15:38:55 -0600
On 26-Oct-05, at 12:17 PM, Ian Hickson wrote: > On Mon, 17 Oct 2005, Ted Goddard wrote: > >> >> Rather than invent another protocol, this seems like an >> excellent application for BEEP: >> >> http://www.ietf.org/rfc/rfc3080.txt >> > > Good lord, that protocol is FAR more complicated than it needs to > be. And > it doesn't address several of the security issues that are critical > here, > such as severly limiting what the initial packets can contain, and > ensuring that the remote host is expecting a connection initiated > by a Web > page of the specified domain. It may be a bit complicated, but BEEP is well suited to exchanging messages over a variety of transports. The flow control mechanism proposed in 6.3.7.3 doesn't allow for pipelining, for instance (remember kermit?). Mike Dierken proposed an HTTP server in the the UA. If BEEP is too complex, at least a pair of HTTP connections could be effectively used for messaging, and would use a well defined protocol with readily available and mature implementations. Providing a back-channel to the browser will revolutionize web applications, so it's worth making fairly robust. >> Restricting connections to the originating host only has shown >> to be fairly effective so far, and it's quite easy to see how >> allowing arbitrary connections (no matter what port they are on) >> could be used to stage attacks on remote servers. Are connections >> to arbitrary hosts worth the risk? >> > > With the protocol as currently designed, connections can only be > established to hosts that are expecting connections from the page's > domain, which massively minimises the risk. (At the moment, it isn't > possible to connect to remote hosts from other domains anyway, but I > imagine we'll relax this in due course.) DNS spoofing aside, that's reasonable ... 6.3.5.1. Broadcasting over TCP/IP IP Multicast would allow multiple UAs on the same host to interact. In particular, this would allow the technology to be demonstrated on a standalone laptop ... How about IP multicast rather than UDP to 255.255.255.255? Ted.
Received on Thursday, 27 October 2005 14:38:55 UTC