Re: Security issues with draft-ietf-tsvwg-iana-ports-08
Gorry Fairhurst <gorry <at> erg.abdn.ac.uk>
2010-11-04 08:21:47 GMT
Thanks Paul,
We should discuss this on the list because this is in WGLC - since this
is a busy time of year for many, here is what I recall of the context:
This issue is being first noted in an I-D in draft-ports, but I do not
recall anybody raised it as a point of discussion. I understood that it
has been the recommendation of the ports review team, whose input is not
binding to IANA nor based on a specific IANA policy.
The general principle is that all new port reservations should support
security, either required or optional (negotiated in-band). I.e., if a
port has significant potential security issues, or if security is
required for firewall traversal, we expect that it will be required. I
understood that the general intent is not so much to prohibit additional
ports for secure variants, but not to recommend ports where security is
an issue and security is NOT supported (i.e., try to avoid the insecure
ones).
I think the intention was that additional ports for secure variants of
existing services would still be endorsed by the ports review team.
(further comments in line).
On 04/11/2010 02:06, 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.
>
That wasn't the reason I recall. I think the principle may
have been to encourage negotiation within a protocol rather
than requiring a dedicated port for each protocol variant
- there are of course lots of existing port assignments some
of which are to protocols that don't behave this way.
> 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
>
I would encourage people to discuss this, now it has been raised,
but please do keep in mind that the actual IANA decisions are informed
by input from the ports review team.
The new proposal for text in section 10.4 also needs specific comments
from the editors.
Hope that helps, and I assume that others will now follow this up,
best wishes,
Gorry
There is a lot of assignation in the current I-D
but
I think that most of it should be changed.
I like too the idea that registration is the request, and that IANA allocates,
and
again, there is a lot of registration and I think that most of it should be
changed.
It is unfortunate that the end result of an allocation by IANA is a registry but
I
do not think that that can be helped
RSS Feed