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

[Joe Touch <[e-mail]>]

PS - attached is a diff of the two XML files, which may make the changes 
more clear.

Joe


On 11/22/2010 11:01 AM, Joe Touch wrote:
> 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]
>> ----------------------------------------------------------------------