[secdir] secdir review of draft-levine-rfb-01

"pat cain" <pcain2@mail2.coopercain.com> Mon, 04 May 2009 22:34 UTC

Return-Path: <pcain2@mail2.coopercain.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D703A6D26; Mon, 4 May 2009 15:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SmOtJysgGEc; Mon, 4 May 2009 15:34:20 -0700 (PDT)
Received: from server1.acmehacking.com (server1.acmehacking.com [72.51.39.79]) by core3.amsl.com (Postfix) with ESMTP id 890443A6822; Mon, 4 May 2009 15:34:20 -0700 (PDT)
Received: from Familyroom (reverse.completel.net [212.99.110.242] (may be forged)) (authenticated bits=0) by server1.acmehacking.com (8.14.3/8.13.8) with ESMTP id n44MZeBW012761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 May 2009 17:35:45 -0500
Received: from Familyroom by Familyroom (PGP Universal service); Mon, 04 May 2009 18:35:41 -0500
X-PGP-Universal: processed; by Familyroom on Mon, 04 May 2009 18:35:41 -0500
From: pat cain <pcain2@mail2.coopercain.com>
To: secdir@ietf.org, draft-levine-rfb@tools.ietf.org
Date: Mon, 04 May 2009 18:35:34 -0400
Message-ID: <014f01c9cd08$a71f7960$f55e6c20$@coopercain.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcnM2wMY+J1M+FtcRKSUjz1RyAkT4Q==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
X-Mailman-Approved-At: Mon, 04 May 2009 22:45:47 -0700
Cc: iesg@ietf.org
Subject: [secdir] secdir review of draft-levine-rfb-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 May 2009 22:34:21 -0000

Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document defines a RFB ("remote framebuffer") protocol for remote 
access to graphical user interfaces.

The security considerations section adequately points out the lack of
security
in the protocol and suggests ways around this issue.

There are a few formatting issues (e.g., the references are not split
between normative and informative) that I expect the rfc editor review will
point out so I will not.

There seems to be lots of 'hidden implications' in this document, for
example there is a line that states "Other security types exist but are not
publicly documented." What happens when two of these non-public things
clash? Or if they are really used, maybe we should document them. :)
The IANA considerations asks for none, but then states that "IANA has
allocated port 5900 to the RFB protocol; the other port numbers have been
used informally and do not match IANA allocations." If only one port was
allocated (but has no reference) how can the 'other ports' not follow the
allocations? (There weren't any other allocations.)

Although it looks like this document is documenting a deployed protocol.
There seems to be a bunch of implementor data missing.

Pat Cain