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

From: <[email-masked]>
Date: Mon, 4 May 2015 01:24:45 -0500

Hi all,

I'd like to than Dominic/RealVNC for reviewing the proposed URI scheme.

Based on his comments I've posted a revised the document available at:
http://www.ietf.org/id/draft-warden-appsawg-vnc-scheme-01.txt

To summarize, as suggested,  I've:
* Provided that userinfo information may be specified/processed but is deprecated.
* Removed the default values for the IdHashAlgorithm, SaveConnection, and SecurityType parameters.
* Renamed ColorModel to ColorLevel and removed the detailed behavior specification. The values still refer to common pixel formats, which I assume is acceptable.
* Clarified the purposes of the SecurityType parameter.
* Removed the LaunchKey parameter.
* Provided that a canonical case should be used, and clients should proves parameter names in a case-insensitive manner.
* Discouraged use of SSLv3.
* Rephrased the certificate verification discussion, providing the clients can automatically verify a certificate, and referred to RFC5280 (on the Internet certificate profile).
* Added a reference to the URL for the IANA schemes registry (although they may eventually move the page).

I've also revised the document a bit to conform to the proposed best practice around scheme registration, including clarifying we conceptually support a "VIEW" operation, although I know the IETF tries to avoid references to pending documents. When adopted, it may be sufficient just to refer to the new RFC number.

Here are some specific responses:

>>Section 2.1 URI Scheme Syntax
>>   A "vnc" URI has the general form:
>>      vnc://host:port?parm1=value1&param2=value2...
>We also feel that there should be a note specifying that password data SHOULD be percent encoded.

I've clarified that password data is often so encoded, but I don't see a benefit to encoding password characters that don't need to be so 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.

I don't think this would be constructive. There is no current use for said component, and if two apps use a path component in different ways, it would be difficult to standardize on such use in the future. In contrast, parameters with application-specific prefixes could move toward standardization via a parameters registry the same way browsers standardize on attributes:
-webkit-xyz, -ms-xyz -> xyz
com.xyz.screenwidth, com.abc.screenwidth -> screenwidth

>> 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&

I don't think we should use namespace aliases because it would substantially increase complexity. In schemes like XML where aliases are common, extensive work is required to deal with issues, such as multiple namespaces, scoping/nesting, prefix reuse, and so on. In any event, it would complicate parameter parsing substantially. If parameter namespaces become common in the future and libraries are made available, perhaps this could be revisited. 

>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&

If possible, I'd like to get more feedback from the group on this. I see arguments both ways:
+ Some precedent with https/http, snews/nntp
+ Can allow for more combinations of VNC security types and tunneling schemes
+ Clean separation of security types/tunnels

- It could require clients to register multiple schemes, and if new security types are used, could lead to an explosion in the number of scheme registrations required, as opposed to just adding a new security type in the IANA registry.
- Not all combinations make a lot of sense, like tunneling AnonTLS over TLS.
- It could make it harder for security software to screen/filter such URIs.
- Clients might still have to connect using SSH from a "vnc:" URI if a connection profile is used.
- Requires changing our current implementation

>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.

I consider this to be outside the scope of this document, because clients usually automatically do a good job of dealing with such configuration, enforcing reasonable key-size minimums and matching keys to compatible suites. I've added a note clarifying this is out of scope. 

Thanks,

David Warden
Dell Enterprise Solutions Group

---

From: t.petch <[email-masked]>
Date: Mon, 4 May 2015 09:12:34 +0100

David

I think that at some point the IANA Considerations should be revisited.

There is a 5226bis which should be referenced (and read!).

That I-D asks that the terminology be Group and Registry, thus avoiding
sub-(sub-(sub-))registry.

It also asks that the IANA Considerations be just explicit directions to
IANA, leaving any technical stuff to the other parts of the document,
making it clear whether this is additions to an existing Group or
Registry or the creation of a new one such. E.g. 'IANA is asked to
create a "VNC ID Hash Algorithms" Registry within the "Remote
Framebuffer (RFB)" Group, so wording it such that 'is asked to create'
can become 'has created' in the hands of the RFC Editor.  I note too
that in this case, the I-D goes on to say
"The registry should include the enumeration
   value, description, and reference document/contact person."
whereas the details are then
"  Value     Description   Reference"
which is not quite the same.

Picky?  Yes, but the more accurate the directions are, the simpler it is
for IANA to do what you want (and who do a magnificent job when
presented with rubbish but deserve better than that:-).

' "Expert Review" or "IESG Approval" process  ' are two quite different
approaches, almost at opposite ends of the spectrum.  For any one
registry, or subset of entries in a registry, I find it hard to see how
both could be applicable.  I would include one or the other (or
something else if appropriate) within the section that asks IANA to
create a new registry.

If you do want Expert Review, then you should give guidance for the
Expert Reviewer to use to judge whether or not to approve an
application.  There has been quite a lot of discussion on this topic in
the context of applications for URI Schemes on this list recently; worth
a look at if you do decide to go with Expert Review.  Expert Review also
means that the IESG have to find and maintain Expert Reviewers with a
suitable level of expertise ( more work for the IESG:-(.

There is also a new version of RFC4395 making its way through the
system; again, worth a read (and a reference).

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Monday, May 04, 2015 7:24 AM
Subject: Re: [apps-discuss] New Proposed VNC URI Scheme

> * Renamed ColorModel to ColorLevel and removed the detailed behavior
specification. The values still refer to common pixel formats, which I
assume is acceptable.
> * Provided that a canonical case should be used, and clients should
proves parameter names in a case-insensitive manner.
> * Rephrased the certificate verification discussion, providing the
clients can automatically verify a certificate, and referred to RFC5280
(on the Internet certificate profile).
> I've also revised the document a bit to conform to the proposed best
practice around scheme registration, including clarifying we
conceptually support a "VIEW" operation, although I know the IETF tries
to avoid references to pending documents. When adopted, it may be
sufficient just to refer to the new RFC number.
> I've clarified that password data is often so encoded, but I don't see
a benefit to encoding password characters that don't need to be so
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.
>
> I don't think this would be constructive. There is no current use for
said component, and if two apps use a path component in different ways,
it would be difficult to standardize on such use in the future. In
contrast, parameters with application-specific prefixes could move
toward standardization via a parameters registry the same way browsers
standardize on attributes:
> >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.:
> I don't think we should use namespace aliases because it would
substantially increase complexity. In schemes like XML where aliases are
common, extensive work is required to deal with issues, such as multiple
namespaces, scoping/nesting, prefix reuse, and so on. In any event, it
would complicate parameter parsing substantially. If parameter
namespaces become common in the future and libraries are made available,
perhaps this could be revisited.
> > 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.
> - It could require clients to register multiple schemes, and if new
security types are used, could lead to an explosion in the number of
scheme registrations required, as opposed to just adding a new security
type in the IANA registry.
> >There should probably be some discussion here about how SSH and TLS
parameters such as cipher suites and version are expected to be
configured.
>
> I consider this to be outside the scope of this document, because
clients usually automatically do a good job of dealing with such
configuration, enforcing reasonable key-size minimums and matching keys
to compatible suites. I've added a note clarifying this is out of scope.
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: <[email-masked]>
Date: Fri, 8 May 2015 01:38:31 -0500

Tom, thanks for the comments. See my notes below.

>-----Original Message-----
>From: t.petch [mailto:[email-masked]] 
> That I-D asks that the terminology be Group and Registry, thus avoiding sub-(sub-(sub-))registry.

> It also asks that the IANA Considerations be just explicit directions to IANA, leaving any technical stuff to the other parts of the document, making it clear whether this is > additions to an existing Group or Registry or the creation of a new one such. E.g. 'IANA is asked to create a "VNC ID Hash Algorithms" Registry within the "Remote ...

I've updated the document in accordance with your recommendations.

>' "Expert Review" or "IESG Approval" process  ' are two quite different approaches, almost at opposite ends of the spectrum.  For any one registry, or subset of entries in >a registry, I find it hard to see how both could be applicable.  I would include one or the other (or something else if appropriate) within the section that asks IANA to >create a new registry.

This language was based on the RFB RFC (RFC6143) which applies to the existing registries. While it is effectively "expert review", it makes it clear the IESG can do whatever it wants without requiring an expert, which may not be obvious to someone reading the document in isolation. I see some value in keeping these consistent. 

The existing registries have values in fixed-length data structures and require some controls that are less necessary in a URI. However, I think it is reasonable to have someone review proposed parameters, and I don't see a lot of new hash algorithms coming along such that a lower standard will make much difference one way or another. 

The use of prefixes for custom parameters provides a safe method for implementation prior to registration, reducing the need for provisional registration like that used in URI schemes. 

> If you do want Expert Review, then you should give guidance for the Expert Reviewer to use to judge whether or not to approve an application.  There has been quite a > lot of discussion on this topic in the context of applications for URI Schemes on this list recently; worth a look at if you do decide to go with Expert Review.  Expert Review > also means that the IESG have to find and maintain Expert Reviewers with a suitable level of expertise ( more work for the IESG:-(.

I've added some basic guidance. I assume I am going to be invited to review any changes for the next thirty years or so after which time cyborg implants will replace remote desktop connectivity. The RFB author Tristan Richardson or his staff would also be excellent reviewers. 

> There is also a new version of RFC4395 making its way through the system; again, worth a read (and a reference).

I've read the update to RFC 4395 and believe this draft meets its requirements. However, I can't easily reference a document that does not have an RFC number, and IETF materials strongly discourage such references to other drafts as it can delay publication. If and when the updates to 4395 and 5226 are published, I will reference them. 

> Tom Petch

Thanks again,

David

---

From: t.petch <[email-masked]>
Date: Mon, 11 May 2015 11:53:18 +0100

---- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, May 08, 2015 7:38 AM

> It also asks that the IANA Considerations be just explicit directions
to IANA, leaving any technical stuff to the other parts of the document,
making it clear whether this is > additions to an existing Group or
Registry or the creation of a new one such. E.g. 'IANA is asked to
create a "VNC ID Hash Algorithms" Registry within the "Remote ...

approaches, almost at opposite ends of the spectrum.  For any one
registry, or subset of entries in >a registry, I find it hard to see how
both could be applicable.  I would include one or the other (or
something else if appropriate) within the section that asks IANA to
>create a new registry.

This language was based on the RFB RFC (RFC6143) which applies to the
existing registries. While it is effectively "expert review", it makes
it clear the IESG can do whatever it wants without requiring an expert,
which may not be obvious to someone reading the document in isolation. I
see some value in keeping these consistent.

The existing registries have values in fixed-length data structures and
require some controls that are less necessary in a URI. However, I think
it is reasonable to have someone review proposed parameters, and I don't
see a lot of new hash algorithms coming along such that a lower standard
will make much difference one way or another.

The use of prefixes for custom parameters provides a safe method for
implementation prior to registration, reducing the need for provisional
registration like that used in URI schemes.

Expert Reviewer to use to judge whether or not to approve an
application.  There has been quite a > lot of discussion on this topic
in the context of applications for URI Schemes on this list recently;
worth a look at if you do decide to go with Expert Review.  Expert
Review > also means that the IESG have to find and maintain Expert
Reviewers with a suitable level of expertise ( more work for the
IESG:-(.

I've added some basic guidance. I assume I am going to be invited to
review any changes for the next thirty years or so after which time
cyborg implants will replace remote desktop connectivity. The RFB author
Tristan Richardson or his staff would also be excellent reviewers.

I've read the update to RFC 4395 and believe this draft meets its
requirements. However, I can't easily reference a document that does not
have an RFC number, and IETF materials strongly discourage such
references to other drafts as it can delay publication. If and when the
updates to 4395 and 5226 are published, I will reference them.

<tp>

Um yes, I should have read RFC6143 more carefully before commenting.  I
see what you mean about having both Expert Review and IESG Approval - I
had not seen that before.  Both place an extra burden on the IESG and I
do see the IESG as a limiting factor in the work of the IETF and so am
always keen to reduce that burden when possible.  Hence my enthusiasm
for other forms of update, such as RFC Required.

You do have a Normative Reference to RFC6143 and RFC6143 is
Informational which means that this is a Downref and one that has not
occurred before AFAICT
http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry#
which is a procedural point for AD Review or IETF Last Call.

I wonder if this I-D should now be Standards Track.  Informational is
always a bit lightweight. Setting up IANA Registries and URIs can and
does happen with Informational but is perhaps less common.  A number of
protocols have started life as Informational and then become Standards
Track or at least in part thereof.

You can reference an I-D by its name as, for example,
draft-ietf-appsawg-rfc7001bis does for I-D draft-kucherawy-dmarc-base.
Yes, it causes publication to be held up but that is not unexpected.

Separately, I wonder if the entries in the new VNC ID Hash Algorithms
registry should be required to appear in another registry, such as the
TLS one, to discourage people from inventing their own i.e. they have to
convince Eric Rescorla of its value before VMC can use it:-)

On the URI itself, I am unsure about
   unreserved-symbols = ":" / "/" / "#" / "[" / "]" / "@" / "!" /
                                 "$" / "'" / "(" / ")" / "*" / "," / ";"
where you are unreserving some gen-delims.  It is hard to say whether or
not RFC3986 prohibits this (it is sometimes hard to say what RFC3986
says:-) but '#' is problematic as is ']'.  The subject of '#' came up
recently on this list with the point being made that generic parsers may
scan backwards and treat the first '#' as being the only one so a second
one will result in misinterpretation.  The whole question of '#' is
fraught as that discussion showed.

While on ']', RFC3986 appears to be quite specific about its use to wit
'A host identified by an Internet Protocol literal address, version 6
   [RFC3513] or later, is distinguished by enclosing the IP literal
   within square brackets ("[" and "]").  This is the only place where
   square bracket characters are allowed in the URI syntax.  '
Again, this surfaced recently on this list and it emerged that there is
one URI definition that is in breach of this, but I do not see that as
an argument for another.

There are others on this list with greater expertise than I in this
matter and I expect you will get more comments on the syntax as some
stage.

Tom Petch

Thanks again,

David

---

From: "John Levine" <[email-masked]>
Date: 11 May 2015 17:01:52 -0000

>see some value in keeping these consistent.

I am trying and failing to remember why we picked that language in
6143.  I think it was just cut and paste from somewhere else.

Personally, I think it should just be expert review.  In the unlikely
even that there's no expert, the IESG should designate one and let her
sort it out.

R's,
John

---

From: t.petch <[email-masked]>
Date: Tue, 12 May 2015 09:23:03 +0100

Responding to my own post to correct a factual error, <tp2>.

Tom Petch

----- Original Message -----
From: "t.petch" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, May 11, 2015 11:53 AM

<tp>

Um yes, I should have read RFC6143 more carefully before commenting.

<tp2> well, it would be if this were a Standards Track I-D which it is
not!  So were it to become a Standards Track I-D, then this would be a
consideration but currently it isn't so it isn't!

Sorry about the error.

</tp2>

<tp3> I am not sure what the rules are for Informational RFC - I have
seen it said, but cannot track down a reference, that it may be ok to
have a Normative Reference to an I-D in a Informational RFC - I will
look some more for that.
</tp3>

 Tom Petch

---

From: <[email-masked]>
Date: Fri, 15 May 2015 14:07:03 -0500

Here are my comments on Tom's suggestions.

----- Original Message -----
From: "t.petch" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, May 11, 2015 11:53 AM

>see what you mean about having both Expert Review and IESG Approval - I had not seen that before.  Both place an extra burden on the IESG and I do see the IESG as a limiting factor in the >work of the IETF and so am always keen to reduce that burden when possible.  Hence my enthusiasm for other forms of update, such as RFC Required.

I've revised the document to remove references to IESG Approval, so it is now "Expert Review" only.

>Separately, I wonder if the entries in the new VNC ID Hash Algorithms registry should be required to appear in another registry, such as the TLS one, to discourage people from inventing their >own i.e. they have to convince Eric Rescorla of its value before VMC can use it:-)

As you've inferred, I was originally thinking there would be value in a "universal" hash algorithms registry since a number of protocols use the same algorithms and have registries with similar content. Some protocols may require slightly different representations (such as a byte value or string) and might use them differently (perhaps requiring all algorithms in the registry be supported). There may be some use for shared registries, however if this is to be someone with at least slightly more ambition and perhaps greater standing with the IETF will need to take this on. 

> where you are unreserving some gen-delims.  It is hard to say whether or not RFC3986 prohibits this (it is sometimes hard to say what RFC3986
> says:-) but '#' is problematic as is ']'.  The subject of '#' came up recently on this list with the point being made that generic parsers may scan backwards and treat the first '#' as being the only 
> one so a second one will result in misinterpretation.  The whole question of '#' is fraught as that discussion showed.

Upon review, it was an error not to keep # and [] reserved and I've updated the document to reflect this. The RFC3986 BNF does not require reservation of  "/" (in the query) and ":", "@" (as a pchar in the query) and they remain unreserved although they are gen-delims. I was playing around with string escape libraries and went a bit too far in reducing the number of reserved characters. 

Regards,

David Warden

---

From: Dominic Parkes <[email-masked]>
Date: Mon, 18 May 2015 09:26:42 +0000

David - thanks for updating your draft. It looks like you've covered most or all of the issues we had concerns over.

>- It could require clients to register multiple schemes, and if new security types are used, could lead to an explosion in the number of scheme registrations required, as opposed to just adding a ne…

We certainly agree that we'd not like to see a large number of new scheme names registered as a result of new security types being implemented.
However - as you are aware (and at the risk of repeating what you've already said) - security types can be negotiated within the RFB protocol's security type negotiation phase (as per RFC6143 - 7.1.2). I.e.: there's normally no need to choose them prior to the RFB connection, or at least not at the viewer side. The only security types that would require another scheme name would be those needing to be set up prior to/outside RFB, like TLS or SSH tunnelling - those that are logically separate.
As they are separate mechanisms, and outside RFB, I do feel that they ought to be outside the vanilla VNC URI scheme too.

Thanks,
Dominic

---

From: <[email-masked]>
Date: Mon, 18 May 2015 15:46:47 -0500

Dominic,

Would you be willing to go along with the addition of a new parameter/registry called something like ConnectionChannel? The connection channel could specify one of the new types (TLS/SSH), traditional TCP, or perhaps IPSec. The SecurityType parameter would remain an option to constrain the negotiation of the traditional RFB security types. 

Clients could optionally support the Secure Tunnel/SSH channel in the SecurityType parameter for backwards compatibility but it would be deprecated.

Note I do see some value into allowing the URI to impose constraints on the security negotiation. If we always negotiate without restriction, an administrator expecting a session with stronger security might inadvertently end up transmitting credentials/data over a session with weaker or no security, and perhaps even to a system controlled by an attacker. At least some existing clients will allow the security type to be (perhaps implicitly) specified and return an error if they cannot negotiate that type. It makes sense to me to extend this to the URI.

Thanks,
David

-----Original Message-----
From: Dominic Parkes [mailto:[email-masked]] 
Sent: Monday, May 18, 2015 4:27 AM
To: Warden, David; [email-masked]
Subject: RE: [apps-discuss] New Proposed VNC URI Scheme

Thanks,
Dominic