RE: [rfbhackers] Comments on RFB 4.0 draft

[Andrew v. d. S. <aj...@gr...>]

Tim,

Thanks for the feedback - some good ideas here. 

SSL versus secsh (the other current alternative). Most platforms have
the equivalent of openssl or CryptoAPI, so we could leverage that for
our encryption. However, many embedded / PDA platforms don't have an SSL
library, which is why secsh is sort of nice as it provides three
functions: authentication, transport (it supports channels), and strong
encryption. SSL only provides encryption. 

I'm hearing you on the vendorID front; the issue for me is to keep the
size of the protocol down and reduce complexity and reduce the ability
for the protocol to be exploited. There's still a potential for
namespace clashes with a URI style. Whether a name is represented by 16
bits or 16 bytes, it's still possible to use the same values. 

I just wanted to make room for a sound channel. It's a common feature
request. I don't necessarily see it happening anytime soon. 

SIP is huge, and not simple at all. SIP suffers from having to interpret
UTF-8 strings as meaningful data. The other issue is that SIP, although
feature rich, is too verbose. Even if we cut down on the amount of verbs
all implementations must implement, we're looking at SIP on top of what
amounts to about 80% of a web server as well as VNC code. 

http://www.ietf.org/rfc/rfc2543.txt

We could allow the use of SIP discovery - but I think SIP is just too
big for VNC. 

SDP is interesting, but the fact that clients and servers will have to
interpret text buffers and make them into machine representations
doesn't gel with the binary protocol that RFB 3.x is, and 4.x should be.
From a security standpoint dealing with arbitrary length Unicode UTF-8
strings to start a session is complex and fills me with fear. 

http://www.ietf.org/rfc/rfc2327.txt

Compared to SIP, secsh's channel architecture is the very essence of
simplicity and more to the point, we can leverage libraries of secsh
code that already exist, thus reducing the amount of time it takes to
get the first implementation working. 

If we go to secsh, I propose that we just utilize the "scp" file
transfer, and potentially allow the transport of IPP or lpr across the
transport. 

Please let me know if I'm way out of line here, but I think we need to
keep the protocol as simple as possible, binary, and cope with the few
extra things that are currently missing. All of the strings in the
current protocol draft are for human consumption, and are easily ignored
by clients and servers alike. 

Andrew


-----Original Message-----
From: sec...@li...
[mailto:sec...@li...] On Behalf Of
Tim Jansen
Sent: Friday, 1 February 2002 8:12 AM
To: sec...@li...
Subject: [rfbhackers] Comments on RFB 4.0 draft

Hi...

A few comments on the RFB 4.0 draft:

- is there a good reason not to use SSL/TLS for encryption and possibly
also 
as an authentication option? The SSL handshake could take place after
the 
authentication mechanism has been negotiated.

- instead of using VendorIDs I would propose to use URIs, similar to the
use 
in XML DTDs or Java package names. This would prevent the possibility of

name clashes.

- IMHO transmitting real-time sound over TCP is not a good idea,
especially 
with lower bandwidth. Skips in audio data are very unpleasant for the
user 
and getting audio right over TCP can be very difficult. RTP is already
there 
and could be used as well.

- I think RFB should be seen in context of SIP. SIP/SDP can establish 
connections and negotiate protocols (like having RFB and RTP in a single

session). Microsoft seems to use it for audio (and a few other things
like 
video) with RDP as well, at least for VoIP.

- several of the other channel types duplicate the functionality of
existing 
RFCs. If you initiate the session using SIP and SDP printers could be 
accessed using IPP, files using HTTP/WebDAV. There is no need to create 
subprotocols in RFB for that. When SSL/TLS is used all these protocols 
(except RTP) could use the same security layer.

- the text encoding sounds somewhat dangerous to me as there may be
different 
font renders on the system (for example one that supports kerning and
one 
that doesnt) or fonts with the same name but slightly different
outlines. 
IMHO caching of bitmaps/glyphs should be sufficient.

bye...






_______________________________________________
Securevnc-rfbhackers mailing list
Sec...@li...
https://lists.sourceforge.net/lists/listinfo/securevnc-rfbhackers