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

[Paul Hoffman <[e-mail]>]

At 8:21 AM +0000 11/4/10, Gorry Fairhurst wrote:
>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).

That's a fine suggestion, but it is not reflected in reality. That is, (nearly?) every modern application protocol of merit has been dual-port, insecure and under-TLS. The IESG has approved these. Why should an IANA policy be the one that dictates the type of security that a protocol designer wants include?

>I think the intention was that additional ports for secure variants of existing services would still be endorsed by the ports review team.

That is not what the draft says. There is no differentiation between existing services and new ones, and given the way that protocols get forked, it is not clear that such a differentiation makes sense.

I assumed that the new rules for security evolved from the emphasis on conservation of ports for the future, as described in 7.2. If that's wrong, and the new rules were there to state a new IETF policy, I think that a different and longer document, sourced by the Security Area, might be more appropriate.

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

As I described in my list, negotiation within a protocol has lots of security faults and has not been embraced. We thought it was a grand idea, and we were shown to be wrong.

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

This is the first I have heard of such a team, and it is mentioned nowhere in this draft; that in and of itself should be fixed. The idea of having new applications work their way all the way through WG consensus and then discover that a ports review team says that their security design is wrong, please start over, does not seem like a good process model.

--Paul Hoffman, Director
--VPN Consortium