Subject: Re: [apps-discuss] New Proposed VNC URI Scheme

From: Dominic Parkes <[email-masked]>
Date: Tue, 28 Apr 2015 11:48:05 +0000

On Tue, Mar 24, 2015 at 2:08 PM, <David_Warden at dell.com> wrote:
>My co-author and I have prepared a proposed VNC URI scheme for review by the community available at:
>http://www.ietf.org/internet-drafts/draft-warden-appsawg-vnc-scheme-00.
>txt

Hi all,

I'm co-ordinating a group at RealVNC with an interest in URI schemes, specifically tasked with looking at the proposal David and Iordan prepared.
First of all: thanks David for putting this forward and reaching out to us. We agree; it would be good to try to standardize use of VNC URI schemes, and you've provided a considered first step toward that.

Here are our comments by section:

Section 2.1 URI Scheme Syntax

>   A "vnc" URI has the general form:
>
>      vnc://host:port?parm1=value1&param2=value2...

Per RFC3986 "username:password@" is deprecated, but we'd like to see some facility for credential passing being recognised here, even if the inclusion of passwords is strongly discouraged. Perhaps the more general "userinfo@" field. Existing VNC viewers such as Apple's Screen Sharing VNC client, and some of our own products use this form.

We also feel that there should be a note specifying that password data SHOULD be percent encoded.

Also on this section - might it be worth allowing an optional path component? This could be used to identify a particular view/monitor or other implementation-specific subdivision. 

Section 2.1.1 URI Parameters

>   o  IdHashAlgorithm, IdHash

Minor point; this perhaps ought not default to SHA1 unless chosen to aid some sort of compatibility with existing implementations.

> o  ColorModel

The name ColorModel implies choosing between representations of color, rather than a pixel format. Perhaps ColorLevel would be more appropriate? Also we feel the default value and behaviour defined here to perhaps be too implementation-specific to include. 

> o  ConnectionName, SaveConnection

The default for saving connections should be that it is up to the implementation - there is a common use case for completely stateless clients launched via URI.

> o  VncUsername, VncPassword, SecurityType

> The VNC client will use this information to determine which parameters 
> are required and establish the connection.

Normal RFB behaviour is that the server lists the security types it can support, and the viewer chooses a valid, supported one. Is this parameter intended to control that negotiation (as well as determining the required parameters)? What happens in the case where the server's security types are not matched by the choice here? Perhaps some clarification is required. 
We feel the default (for widest compatibility) should be to allow the normal security handshake to occur.

> o  LaunchKey

This is a licensing feature which would seem to be quite implementation specific. We'd prefer that the scheme mentions that other unspecified parameters may exist (as per the note about distinguishing prefixes).

>   Parameter names and values shall be interpreted in a case sensitive manner, unless otherwise noted.

Case sensitivity - in order to support the widest range of existing and future implementations perhaps it would be better to specify a canonical case for each parameter, which SHOULD be used, but that clients SHOULD also accept them as case-insensitive?

> VNC Clients supporting  application-specific parameters SHOULD include 
> a distinguishing prefix within the parameter name [...]
> 
>    vnc://?com.dell.vncclient.ScreenMode=2&

This seems like a good idea - perhaps we could specify a facility to define a namespace alias and encourage people to use it for multiple arguments, e.g.: 

  vnc://?ns.Dell=com.dell.vncclient&Dell.SecurityType=1&Dell.ViewOnly=true&

Section 2.3 Integrated Security Types

A broad comment on this section is that we'd prefer a scheme which attempts to separate SSH and TLS tunnel security types from a more basic VNC URI specification. Perhaps with a scheme looking something like this:

  vnc+ssh://hostname:port/?parameter=value&

2.3.1 The "Integrated SSH" Security Type &
  2.3.2 The "Secure Tunnel" Security Type

There should probably be some discussion here about how SSH and TLS parameters such as cipher suites and version are expected to be configured.

>   Since the TLS protocol provides backwards compatibility with SSLv3,
>   and SSL tunnel MAY be used if supported.

Perhaps add a note discouraging the use of SSLv3? (https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-03). 

>      When providing identifying information of a host identified by an
>      X509 certificate [x.509], the certificate subject, issuer,
>      validity period, and certificate hash MUST be included.  The VNC
>      client MAY give users the option of verifying the certificate
>      name, certificate authority, certificate revocation list, and
>      validity period.  If information on the validity of a certificate
>      is not displayed, the console application MUST include a
>      statement indicating such information has not been verified.

Should this also include the option that the client verifies the certificate automatically? Perhaps add a reference to the relevant RFC (2818?).

Section 4. IANA Considerations

> The "vnc" scheme should be registered in the URI schemes registry.

This should have a specific reference to http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

Thanks,
Dominic Parkes
RealVNC Ltd.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 28 Apr 2015 11:13:01 -0700

> On Apr 28, 2015, at 4:48 AM, Dominic Parkes <[email-masked]> wrote:
> 

FYI, how we handled that for HTTP is in RFC7230, sec. 2.7.1:

   The URI generic syntax for authority also includes a deprecated
   userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
   authentication information in the URI.  Some implementations make use
   of the userinfo component for internal configuration of
   authentication information, such as within command invocation
   options, configuration files, or bookmark lists, even though such
   usage might expose a user identifier or password.  A sender MUST NOT
   generate the userinfo subcomponent (and its "@" delimiter) when an
   "http" URI reference is generated within a message as a request
   target or header field value.  Before making use of an "http" URI
   reference received from an untrusted source, a recipient SHOULD parse
   for userinfo and treat its presence as an error; it is likely being
   used to obscure the authority for the sake of phishing attacks.

Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <http://www.adobe.com/>