Re: Security issues with draft-ietf-tsvwg-iana-ports-08

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 06 November 2010 02:00 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 9B1143A6778 for <tsvwg@core3.amsl.com>; Fri, 5 Nov 2010 19:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.778
X-Spam-Level:
X-Spam-Status: No, score=-98.778 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, DATE_IN_FUTURE_12_24=2.189, HELO_MISMATCH_COM=0.553, 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 0oFKBQRmq+HH for <tsvwg@core3.amsl.com>; Fri, 5 Nov 2010 19:00:13 -0700 (PDT)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C96593A63C9 for <tsvwg@ietf.org>; Fri, 5 Nov 2010 19:00:13 -0700 (PDT)
Received: from [10.20.30.150] ([222.128.202.158]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oA620JCi026367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Nov 2010 19:00:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0624082dc8fb3842cc69@[10.20.30.150]>
In-Reply-To: <4CD4B053.8010001@ericsson.com>
References: <4CCD6B0B.5040804@isode.com> <p06240842c8f7b9ba2577@[10.20.30.150]> <4CD27ECF.1010500@cisco.com> <p06240802c8f8882552b4@[10.20.30.150]> <4CD2FAEB.5020606@cisco.com> <4CD4B053.8010001@ericsson.com>
Date: Sat, 06 Nov 2010 10:00:17 -0700
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Eliot Lear <lear@cisco.com>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: Security issues with draft-ietf-tsvwg-iana-ports-08
Content-Type: text/plain; charset="us-ascii"
Cc: "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: Sat, 06 Nov 2010 02:00:14 -0000

At 2:33 AM +0100 11/6/10, Magnus Westerlund wrote:
>Eliot Lear skrev 2010-11-04 19:26:
> > Hi Paul,
>>
>> I think you've raised some really good points, but I am still concerned
>> about one issue, and I'm not sure this draft is the place to fix it: if
>> applicants are left with the impression that IANA won't allocate another
>> port for additional security, perhaps they get to think about it NOW.
>> If on the other hand, they think they can always apply later, they will
>> think about it LATER.  I would rather they think about it NOW.  In
>> practice I don't know that they actually will think about it NOW, but
>> rather simply reserve a means to STARTTLS (or the like), and so again, I
>> don't if we can fix this one.  That just leaves stewardship.
>>
>> Eliot
>
>Paul and Eliot,
>
>I have to agree with Eliot here. I clearly can understand your view on
>how things has been and are. I would like to start with pointing out
>that most ports allocated to protocols each years are not done by IETF,
>nor discussed in IETF at all.

Understood. That is one of the reasons I wanted to do the "reserve 50 ports for 'second port for security' and see what happens to them. We would have much better data about where those assignments are coming from. I also purposely picked an oddball set of ports so that people who said "we want n for the protocol and n+1 for protocol-over-TLS" would instead get n and something inconvenient to type.

>We also know that if considered from start there is little issue with
>doing TLS and non TLS on the same port.

Which "we" are you talking about here? :-) I have not seen any protocols that considered it from the start that don't have essentially all of the problems of SMTP with STARTTLS, as described in RFC 3207, but I could have missed them.

>I agree that retrofitting an old
>protocol is not necessarily as easy nor deployable. I do expect the port
>review team will actually approve a request for a second port if there
>is shown need.

The current wording would prohibit that; thus, my proposed change.

>I think the issue here is to strike a balance in the text so that it is
>clear that for existing protocol it might be possible to get a second
>port, but we really do expect new protocols to have support from the
>start to do TLS on that single port.

Same question: who is the "we" here? I suspect that in this case you mean the IESG, and if you are actually going to enforce that, I'm happy. I'm also skeptical, and my skepticism isn't helped by the fact that this significant security protocol design guideline is buried in an IANA document that came from TSV, not Security.

>I also think reserving ports for old protocols is a bad idea. We have no
>immediate shortage of ports, if I remember Joe's calculations correctly
>our current consumption rate would result in run out for TCP in around
>50 years. Thus reserving for this purpose seems strange, as the
>protocols that do truly need a second port can get one. So to avoid
>sending a message, that I don't want to send nor reserve ports when not
>needed I think this idea should be skipped.

We fully agree here. If there is anything in my proposed wording that suggested that all old protocols get a second port without asking, I am happy to change it. To date, I haven't heard of anyone in the Apps area who wanted this.

--Paul Hoffman, Director
--VPN Consortium