Hi there,
I'd certainly like to be included in your version 5.0 protocol. Everything
should be backward compatible, ie a 3.0 client should be able to
authenticate to a 5.0 server, as long as the 5.0 server allows it.
The main reason I chose for incrementing the rev by a whole number is simply
because the authentication mechanism must change to stay with current
thinking on secure protocol design. If 5.0 is in design stage, please let me
add my few changes in, and I'll stick with that. I feel that 0.1 increments
are worthwhile when protocol bugs are fixed, or minor new features are
added, like sound. Changing the authentication mechanism is a major change.
The criteria for safe protocol design are:
* strong typing and sizing of data
* strong checks of data before being utilised
* minimal anonymous disclosure for fingerprinting
* minimal overhead by anonymous users until after successful authentication
* not replayable
* minimal MITM risks (ie if you sniff the auth stuff what can be fudged or
reversed)
Goals:
* low latency design (ie as few client-server steps as possible)
* scalable in case VNC suddenly needs to work with a large number
simultaneous users
* all current optional extensions and encodings are gathered into one
reference
Desired new features:
* opaque blob authenticator for Kerberos, OpenSSL, etc
Andrew
----- Original Message -----
From: "Jonathan Morton" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 16, 2001 8:29 PM
Subject: Re: RFB Protocol 4.0 - encodings wanted
> >We already use RFB version 4.x in some of our projects. We're now
developing
> >version 5.0 of the protocol which is a substantial change from the
version 3
> >protocols. It would be good to coordinate over what version number you
choose
> >for your new protocol so that we don't release incompatible protocols
which
> >claim to be the same version number. That would be bad :-)
>
> Strongly agree. I'm sticking to v3.x for my proposals documentation,
> since I don't see any immediate reason to make substantially
> incompatible changes. I gather the v3.x numberspace is open for this
> kind of use, given that AT&T have already moved beyond this? I
> suspect v3.x software will remain in use for some considerable time
> to come...
> --
> --------------------------------------------------------------
> from: Jonathan "Chromatix" Morton
> mail: [EMAIL PROTECTED] (not for attachments)
> website: http://www.chromatix.uklinux.net/vnc/
> geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O--
M++$
> V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
> tagline: The key to knowledge is not to rely on people to teach you it.
> ---------------------------------------------------------------------
> To unsubscribe, send a message with the line: unsubscribe vnc-list
> to [EMAIL PROTECTED]
> See also: http://www.uk.research.att.com/vnc/intouch.html
> ---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
