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

Joe Touch <touch@isi.edu> Tue, 23 November 2010 17:07 UTC

Return-Path: <touch@isi.edu>
X-Original-To: port-srv-reg@core3.amsl.com
Delivered-To: port-srv-reg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981393A6848 for <port-srv-reg@core3.amsl.com>; Tue, 23 Nov 2010 09:07:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.563
X-Spam-Level:
X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6hNTPuuLc51 for <port-srv-reg@core3.amsl.com>; Tue, 23 Nov 2010 09:07:05 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 6BF183A6881 for <port-srv-reg@ietf.org>; Tue, 23 Nov 2010 09:07:05 -0800 (PST)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id oANH7HDR010073 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 23 Nov 2010 09:07:17 -0800 (PST)
Message-ID: <4CEBF4C5.5020001@isi.edu>
Date: Tue, 23 Nov 2010 09:07:17 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <4CE3AD8E.4070705@ericsson.com> <4CE47714.50806@isi.edu> <4CE4D9E1.5010308@ericsson.com> <4CEABE0E.7050209@isi.edu> <4CEABEAC.70307@isi.edu> <4CEBD261.5080101@ericsson.com>
In-Reply-To: <4CEBD261.5080101@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MailScanner-ID: oANH7HDR010073
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "port-srv-reg@ietf.org" <port-srv-reg@ietf.org>
Subject: Re: [port-srv-reg] Updating the draft with WGLC comments
X-BeenThere: port-srv-reg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of updates to service name and transport protocol port registry <port-srv-reg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/port-srv-reg>, <mailto:port-srv-reg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/port-srv-reg>
List-Post: <mailto:port-srv-reg@ietf.org>
List-Help: <mailto:port-srv-reg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/port-srv-reg>, <mailto:port-srv-reg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Nov 2010 17:07:06 -0000

Just tell me what the preferred phrase is, and I can do a pass.

Joe

On 11/23/2010 6:40 AM, Magnus Westerlund wrote:
> 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 +46 10 7148287
>>>> Färögatan 6 | Mobile +46 73 0949079
>>>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>>>> ----------------------------------------------------------------------
>
>