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.

First, I should probably apologize. I am the author of RFC 2487 (updated by RFC 3207), the now-infamous "STARTTLS" option for SMTP. It seemed like a good idea at the time, it really did. No need for a second port and possible delays due to port-probing: just do an in-band security upgrade. And it could work with other common application protocols like POP and IMAP as well (RFC 2595)!

History has shown us wrong, but draft-ietf-tsvwg-iana-ports ignores that history. In short:

- There are serious security drawbacks to doing in-band upgrades within SMTP. Notice the large number of new attack descriptions and warnings in RFC 3207.

- The processing model for how to change state after the STARTTLS command was more complicated than what we thought, whereas it is completely clear what it means for applications over TLS on a second port.

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

- SIP's two-port scheme has worked incredibly well.

- Having multiple code paths for "now you are in the clear" and "now you are under TLS" has proven to expose some serious security risks that do not exist for when a second port is used.

- Attempts to create TLS-like encryption and/or integrity protection without actually doing TLS usually ends up with security holes not in TLS.

- The number of new application protocols created over the past decade is significantly lower than was expected.

Given this, and recognizing that the resource scarcity of port numbers is a real concern for the long term, I propose the following changes to draft-ietf-tsvwg-iana-ports:

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.

Section 7.2 current:
   Further,
   previous separation of protocol variants based on security
   capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is
   not recommended for new protocols, because all new protocols should
   be security-capable and capable of negotiating the use of security
   in-band.

Section 7.2 proposed:
   Further, previous separation of protocol variants based on security
   capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is
   allowed for new protocols as long as they meet the requirements above.

Section 9 current:
   Services are expected to include support for security, either as
   default or dynamically negotiated in-band.  The use of separate
   service name or port number assignments for secure and insecure
   variants of the same service is to be avoided in order to discourage
   the deployment of insecure services.

Section 9 proposed:
   Services are expected to include support for security, either as
   default, through a separate port using TLS, or dynamically
   negotiated in-band.  The use of non-protected variants of services
   (that is, clear text with no encryption or integrity assurance)
   continues to be discouraged in IETF standards, although it is still
   unfortunately a common occurrence even in new protocols.

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.

That last proposal should cover the port-scarcity concerns, and a future IESG will have a much better idea of the run rate on ports-for-security if they are all taken from one place starting now.

I am happy to discuss this more at the TSVWG meeting in Beijing if people want.

--Paul Hoffman, Director
--VPN Consortium