Re: Proposed resolution for security issues with draft-ietf-tsvwg-iana-ports-08

[Eliot Lear <[e-mail]>]

Right.  The policy needs to express strong reticence toward additional
port assignments, with the expectation that it will be hard to get an
exception.

On 11/17/10 11:20 AM, Magnus Westerlund wrote:
> Hi Paul,
>
> Many thanks for suggesting a way forward on your last call comment.
>
> I think this resolution is in general fine with me. In the name of port
> space preserving, I would desire a somewhat stronger formulation in the
> first change about that you really shouldn't expect IANA to allocate you
> more than one port number per protocol.
>
> Cheers
>
> Magnus
>
> Paul Hoffman skrev 2010-11-15 20:44:
>> As this list and the TLS has seen, there is a wide variety of views on how to deal with fallback-to-insecure in protocols. I believe that the security community has no consensus on what this means, much less how to do it. My earlier proposal (continue to allow registration of two ports) was popular with some, unpopular with others; similarly, so was "force all protocols to use one port".
>>
>> Therefore, I retract my proposal to allow two-port registrations for fallback-to-insecure. However, I still recommend some changes to the text to reflect the view that STARTTLS is not the only way to have such a feature on one port.
>>
>> This will be an interesting IETF Last Call discussion.
>>
>> 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 current:
>> o  IANA will normally 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). This policy can
>>    be overridden by the expert reviewer.
>>
>> 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
>>    not recommended for new protocols, because all new protocols should
>>    be security-capable.
>>
>> --Paul Hoffman, Director
>> --VPN Consortium
>>
>