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

Paul Hoffman <> Mon, 08 November 2010 09:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A652F3A690A for <>; Mon, 8 Nov 2010 01:18:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.419
X-Spam-Status: No, score=-101.419 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x0h-qeGEd-D3 for <>; Mon, 8 Nov 2010 01:18:42 -0800 (PST)
Received: from (Hoffman.Proper.COM []) by (Postfix) with ESMTP id D01AF3A68A2 for <>; Mon, 8 Nov 2010 01:18:42 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.3) with ESMTP id oA89ItYW064919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Nov 2010 02:18:58 -0700 (MST) (envelope-from
Mime-Version: 1.0
Message-Id: <p06240844c8fd6ec914fb@[]>
In-Reply-To: <>
References: <> <p06240842c8f7b9ba2577@[]> <> <p06240802c8f8882552b4@[]> <> <> <p0624082dc8fb3842cc69@[]> <>
Date: Mon, 08 Nov 2010 17:18:53 +0800
To: Magnus Westerlund <>
From: Paul Hoffman <>
Subject: Re: Security issues with draft-ietf-tsvwg-iana-ports-08
Content-Type: text/plain; charset="us-ascii"
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 09:18:43 -0000

At 10:48 AM +0800 11/8/10, Magnus Westerlund wrote:
>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.

True. Is that done in any IETF protocols? I know people thought about this, but I thought they all had rejected it, but I easily could have missed something.

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

Dang, I wish we had documented this decision tree in RFC 3207.

There is a *huge* difference here. If the protocol has an upgrade/downgrade option, the state machine needs to have at least one place for the server to decide whether or not it wants a downgrade as well as at least one "has this client upgrade it yet?" place. With two ports, you just don't turn on the unsecured port.

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

If we can get statistics such as "number of second ports for application protocols in the past three years", that would be great.

--Paul Hoffman, Director
--VPN Consortium