Re: [port-srv-reg] Updating the draft with WGLC comments

[Joe Touch <[e-mail]>]

See attached as a way to address the concerns.

Basically, I clarified that these are NOT binding (many times), and 
changed the word to "strives" (i.e., implying a goal), rather than 
indicating it as a hard rule.

Let me know if it answers the mail, or if I can help adjust further.

Joe

On 11/17/2010 11:46 PM, Magnus Westerlund wrote:
> Joe Touch skrev 2010-11-18 01:45:
>> Hi, Magnus,
>>
>> The feedback from Paul suggests it would be useful to update Sec 7.
>>
>> Despite the explicit warning - already in the doc - that these
>> principles are NOT binding, it might be useful to discuss the issue of
>> whether separate ports should be allocated for requests for new protocols.
>>
>> I.e., http vs https is currently legacy. We already expect that new
>> requests for nonsecure legacy services could result in a new, secure port.
>>
>> The question is whether a brand new service should be allocated separate
>> ports for secure and nonsecure variants.
>>
>> The document discusses this point as follows:
>>
>>      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)
>>
>> ...
>>     - 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.
>>
>> Here's the TLS summary
>> 	for:
>> 		Mike D'Errico
>> 		Nico Williams
>> 	against:
>> 		Paul Hoffman
>> 		Marsh Ray - really just wants default to secure
>> 		Richard Hartman
>>
>> Some just wanted security all the time:
>> 	Geoffry Keating
>> 	Mike D'Errico
>>
>> I didn't see that they came to consensus on this issue. We can easily
>> omit the security text altogether from this text if preferred, and let
>> the TLS community make a final BCP recommendation.
>>
>> However, despite their status as security experts, I find their logic
>> disturbing. Port numbers themselves have no inherent security, so
>> ultimately only the application can require a service to be secure
>> anyway. Using port number blocking to assume security is laughable at
>> best, so I stand by the current text.
>>
>> IMO we already have enough wiggle words that this section isn't binding
>> anyway. IMO, let the TLS folk create a BCP to the contrary, at which
>> point some of us (me at least) will write a doc explaining why port
>> numbers aren't security anyway ;-)
>
> My view is that there seem to be no real security benefit from running
> separate ports generally. One anyway has to live with the downgrade
> attacks etc. Thus I think port space preservation is still the main goal.
>
>>
>> Thoughts? Leave it? Take it out because a non-consensus subset disagrees?
>>
>
> I would do some minor tweaks, at least to the following sentence:
>
> 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)
>
> People interpret the "will allocate only" very strict. I think we can
> reword this to be one degree less strict. like:
>
> IANA will with extremely few exceptions 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)
>
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------