Re: Proposed resolution for security issues with draft-ietf-tsvwg-iana-ports-08

Eliot Lear <lear@cisco.com> Wed, 17 November 2010 11:05 UTC

Return-Path: <lear@cisco.com>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FBAD3A68D2 for <tsvwg@core3.amsl.com>; Wed, 17 Nov 2010 03:05:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.866
X-Spam-Level:
X-Spam-Status: No, score=-109.866 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 HBNPnMWJBcgv for <tsvwg@core3.amsl.com>; Wed, 17 Nov 2010 03:05:39 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3D7063A68DB for <tsvwg@ietf.org>; Wed, 17 Nov 2010 03:05:39 -0800 (PST)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq0DAG5F40yQ/khLgWdsb2JhbACDSJ55FQEBFiIipTKKNZBngSKDNnMEilg
X-IronPort-AV: E=Sophos;i="4.59,210,1288569600"; d="scan'208";a="69438056"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 17 Nov 2010 11:06:23 +0000
Received: from dhcp-10-61-99-165.cisco.com (dhcp-10-61-99-165.cisco.com [10.61.99.165]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oAHB6N8s006725; Wed, 17 Nov 2010 11:06:23 GMT
Message-ID: <4CE3B73F.5040409@cisco.com>
Date: Wed, 17 Nov 2010 12:06:39 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Subject: Re: Proposed resolution for security issues with draft-ietf-tsvwg-iana-ports-08
References: <p06240824c9073b8e611a@[10.20.30.150]> <4CE3AC6F.1030402@ericsson.com>
In-Reply-To: <4CE3AC6F.1030402@ericsson.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Nov 2010 11:05:40 -0000

Right.  The policy needs to express strong reticence toward additional
port assignments, with the expectation that it will be hard to get an
exception.

On 11/17/10 11:20 AM, Magnus Westerlund wrote:
> Hi Paul,
>
> Many thanks for suggesting a way forward on your last call comment.
>
> I think this resolution is in general fine with me. In the name of port
> space preserving, I would desire a somewhat stronger formulation in the
> first change about that you really shouldn't expect IANA to allocate you
> more than one port number per protocol.
>
> Cheers
>
> Magnus
>
> Paul Hoffman skrev 2010-11-15 20:44:
>> As this list and the TLS has seen, there is a wide variety of views on how to deal with fallback-to-insecure in protocols. I believe that the security community has no consensus on what this means, much less how to do it. My earlier proposal (continue to allow registration of two ports) was popular with some, unpopular with others; similarly, so was "force all protocols to use one port".
>>
>> Therefore, I retract my proposal to allow two-port registrations for fallback-to-insecure. However, I still recommend some changes to the text to reflect the view that STARTTLS is not the only way to have such a feature on one port.
>>
>> This will be an interesting IETF Last Call discussion.
>>
>> I propose the following changes to draft-ietf-tsvwg-iana-ports:
>>
>> Section 7.2 current:
>> 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)
>>
>> Section 7.2 current:
>> o  IANA will normally 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). This policy can
>>    be overridden by the expert reviewer.
>>
>> Section 7.2 current:
>>    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.
>>
>> Section 7.2 proposed:
>>    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.
>>
>> --Paul Hoffman, Director
>> --VPN Consortium
>>
>