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

Magnus Westerlund <> Mon, 08 November 2010 02:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FDBA3A6952 for <>; Sun, 7 Nov 2010 18:49:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.649
X-Spam-Status: No, score=-106.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TeqwWLFjcq+x for <>; Sun, 7 Nov 2010 18:49:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3DB273A6951 for <>; Sun, 7 Nov 2010 18:49:04 -0800 (PST)
X-AuditID: c1b4fb39-b7b54ae000003464-6f-4cd765338c22
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 33.A8.13412.33567DC4; Mon, 8 Nov 2010 03:49:23 +0100 (CET)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Nov 2010 03:48:22 +0100
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Nov 2010 03:48:21 +0100
Message-ID: <>
Date: Mon, 08 Nov 2010 10:48:17 +0800
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv: Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Paul Hoffman <>
Subject: Re: Security issues with draft-ietf-tsvwg-iana-ports-08
References: <> <p06240842c8f7b9ba2577@[]> <> <p06240802c8f8882552b4@[]> <> <> <p0624082dc8fb3842cc69@[]>
In-Reply-To: <p0624082dc8fb3842cc69@[]>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 08 Nov 2010 02:48:21.0973 (UTC) FILETIME=[68250050:01CB7EEF]
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Nov 2010 02:49:06 -0000

Paul Hoffman skrev 2010-11-07 01:00:
> 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.

Ok, I don't know about that. I did a bit of looking on the number of
port numbers that includes TLS in their comments fields. It appears that
the number is around 55 ports assigned today for TCP (106 occurrences at Searching for SSL (184
hits), Secure (157 hits). Considering that most TCP based protocols also
got an UDP port, the actual number of services using TLS/SSL or being
for the secure version seems to be around 100.

This number is pretty low compared to the number of port assignments
every year that are around 400 per year.

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

Sorry, I was probably way to loose with WE here.

Also, STARTTLS is not the only way of using TLS on a joint port. If you
can de-mux TLS requests and unsecured ones on the same port without
needing an initiation command then things would work differently.

Also, I don't see why the security considerations for STARTTLS like the
man in the middle isn't similar for operation over two ports. If you can
fiddle with the packet in flight, you can probably block or interfere
with the TLS setup also. Thus forcing fallback to unsecure.

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

Here I did mean the author team. I would appreciate some input from the
security area on this issue.

As I see it if we make using different ports for TLS and a non-secure
version we basically double the port usage for protocols that needs TLS
type security. Thus increasing the port usage significantly.

I don't want to ignore this issue, but the question here is how to do
the trade-off between getting more long lived usage out of the port
registry and have reasonable implementation burden and security properties.

So far I am personally leaning towards the custodian of the port space
view but are willing to convinced that the downsides are so bad that we
do need to consume more port space.

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

No, I didn't mean to imply that they would get it without asking for it.
But I do know understand your intention with the reservation. I think we
can probably get the statistics without having a special range. If we
want a disincentive by using a range that is another question.


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: