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

[Magnus Westerlund <[e-mail]>]

Hi,

I think these changes are fine. That still leaves the changes regarding
the usage of allocation vs assign and register. Is anyone willing to
take this on. I would love, however, my son has been sick (just a cold)
but it has resulted in me missing a number of work hours making it
difficult for me to keep up with things. So I would love if someone was
willing to do this pass.

Cheers

Magnus

Joe Touch skrev 2010-11-22 20:04:
> 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]
>>> ----------------------------------------------------------------------


-- 

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