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

[Joe Touch <[e-mail]>]

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