Re: [port-srv-reg] Updating the draft with WGLC comments
Joe Touch <touch@isi.edu> Thu, 18 November 2010 19:44 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 CAB343A68CF for <port-srv-reg@core3.amsl.com>;
Thu, 18 Nov 2010 11:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Level:
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028,
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 UB9j49eRghEK for
<port-srv-reg@core3.amsl.com>; Thu, 18 Nov 2010 11:44:50 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by
core3.amsl.com (Postfix) with ESMTP id C9DEC3A6832 for
<port-srv-reg@ietf.org>; Thu, 18 Nov 2010 11:44:50 -0800 (PST)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated
bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oAIJiVxS004220
(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);
Thu, 18 Nov 2010 11:44:32 -0800 (PST)
Message-ID: <4CE58220.9070206@isi.edu>
Date: Thu, 18 Nov 2010 11:44:32 -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>
In-Reply-To: <4CE4D9E1.5010308@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-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: Thu, 18 Nov 2010 19:44:51 -0000
Hi, Magnus, Sure - maybe just changing the words throughout that section to imply less of a requirement than a recommendation would be sufficient. I can take a stab at that if someone can email the source (sorry - I have problems getting at SVN from Windows) 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 > ----------------------------------------------------------------------
- [port-srv-reg] Updating the draft with WGLC comme… Magnus Westerlund
- Re: [port-srv-reg] Updating the draft with WGLC c… Joe Touch
- Re: [port-srv-reg] Updating the draft with WGLC c… Magnus Westerlund
- Re: [port-srv-reg] Updating the draft with WGLC c… Joe Touch
- Re: [port-srv-reg] Updating the draft with WGLC c… Lars Eggert
- Re: [port-srv-reg] Updating the draft with WGLC c… Joe Touch
- Re: [port-srv-reg] Updating the draft with WGLC c… Joe Touch
- Re: [port-srv-reg] Updating the draft with WGLC c… Magnus Westerlund
- Re: [port-srv-reg] Updating the draft with WGLC c… Joe Touch
- Re: [port-srv-reg] Updating the draft with WGLC c… Magnus Westerlund
- Re: [port-srv-reg] Updating the draft with WGLC c… Lars Eggert
- Re: [port-srv-reg] Updating the draft with WGLC c… Joe Touch
- Re: [port-srv-reg] Updating the draft with WGLC c… Joe Touch
- Re: [port-srv-reg] Updating the draft with WGLC c… Joe Touch
- Re: [port-srv-reg] Updating the draft with WGLC c… Magnus Westerlund
- Re: [port-srv-reg] Updating the draft with WGLC c… Magnus Westerlund