Re: Security issues with draft-ietf-tsvwg-iana-ports-08

Joe Touch <touch@isi.edu> Tue, 09 November 2010 19:52 UTC

Return-Path: <touch@isi.edu>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313C73A6879 for <tsvwg@core3.amsl.com>; Tue, 9 Nov 2010 11:52:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 bAG86M5mRyGA for <tsvwg@core3.amsl.com>; Tue, 9 Nov 2010 11:52:25 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 264273A6848 for <tsvwg@ietf.org>; Tue, 9 Nov 2010 11:52:25 -0800 (PST)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id oA9JqcJq016090 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 9 Nov 2010 11:52:38 -0800 (PST)
Message-ID: <4CD9A686.9040903@isi.edu>
Date: Tue, 09 Nov 2010 11:52:38 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: Security issues with draft-ietf-tsvwg-iana-ports-08
References: <4CCD6B0B.5040804@isode.com> <p06240842c8f7b9ba2577@[10.20.30.150]>
In-Reply-To: <p06240842c8f7b9ba2577@[10.20.30.150]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: oA9JqcJq016090
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2010 19:52:26 -0000

On 11/3/2010 7:06 PM, Paul Hoffman wrote:
> Greetings again. There is a new restriction in
> draft-ietf-tsvwg-iana-ports that will have a negative effect on the
> overall security of the Internet. Two restrictions in section 7.2 and
> the related one in section 9 prevent protocol designers from getting
> a second port for a secure (likely TLS-wrapped) version of their
> protocol based on wishful thinking that does not represent extensive
> reality in deploymet. I propose alternate wording below.

It's important to note that this is not a "restriction".

Sec 7.2 states:
    This section summarizes the basic principles by which IANA handles
    the Service Name and Transport Protocol Port Number Registry, and
    attempts to conserve the port number space.  This description is
    intended to inform applicants requesting service names and port
    numbers.  IANA are not required to be bound by these principles when
    handling requests; other factors may come into play, and exceptions
    may occur where deemed in the best interest of the Internet.

I.e., the goal of 7.2 is to explain the basic principles of the 
approach, but it IS NOT BINDING.

The key point, IMO, should be:

> - POP and IMAP have well-known upgrade semantics as well as each
> having a second port for TLS. Nearly all implementations use the second
> port, and interoperability for the upgrade mechanism was not widespread
> when it was last tested.

History has shown many things -- I would argue that foremost among these 
is that port numbers are a horrible place to assume security.

In general, a port opens a service, and the service determines security 
anyway, so that's the model that makes most sense to me. In particular, 
the assumption is that security should be supported in all new 
assignments, and that when it is optional, that is a decision within the 
protocol.

...
> Section 7.2 current:
> o  IANA will allocate only one assigned port number for all versions
>     of a service (e.g., running the service with or without a security
>     mechanism, or for updated variants of a service)
>
> Section 7.2 proposed:
> o  IANA will allow the allocation of one additional assigned port number
>     for a service that runs without security and with security if the
>     second port is used for running that service under TLS. The
>     application definition MUST say which version of TLS is to be run on
>     the additional port, SHOULD use the most current version of TLS, and
>     MUST say if there are cryptographic requirements beyond those in the
>     TLS version used.

This is a severe concern; it basically doubles the allocation rate.

Further, the new language includes 2119-level language; this isn't 
appropriate, since this document is not binding anyway.

> Proposed new section 10.4:
>     IANA will reserve 50 port numbers, 21850-21899, to be allocated for
>     secure versions of new or revised protocols. Future IETF standards
>     actions and/or BCPs may recover unused values in this range, or they
>     may reserve more port numbers specifically for additional ports
>     for security.

First, all new protocols should support security, IMO (call that SHOULD 
if you want).

Second, as noted above, port numbers are a horrible place to assume 
security per se. It's trivial for services to override them.

I am not in Beijing, but can continue this discussion via email...

Joe