Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)

Nicolas Williams <> Mon, 08 November 2010 20:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CB333A686D; Mon, 8 Nov 2010 12:24:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.398
X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EPEoKNyCTOCO; Mon, 8 Nov 2010 12:24:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 693413A6834; Mon, 8 Nov 2010 12:24:04 -0800 (PST)
Received: from ( []) by (Switch-3.4.2/Switch-3.4.2) with ESMTP id oA8KON7r030895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Nov 2010 20:24:24 GMT
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id oA8K6Dm5026497; Mon, 8 Nov 2010 20:24:21 GMT
Received: from by with ESMTP id 760081711289247852; Mon, 08 Nov 2010 12:24:12 -0800
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Nov 2010 12:24:12 -0800
Date: Mon, 08 Nov 2010 14:24:08 -0600
From: Nicolas Williams <>
To: Marsh Ray <>
Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)
Message-ID: <>
References: <> <p06240843c8fd6c508084@[]> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Mailman-Approved-At: Tue, 09 Nov 2010 00:06:07 -0800
Cc:, Paul Hoffman <>,
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 20:24:05 -0000

On Mon, Nov 08, 2010 at 11:27:46AM -0600, Marsh Ray wrote:
> On 11/08/2010 03:07 AM, Paul Hoffman wrote:
> >
> >"some security issues": See the long Security Considerations section
> >on RFC 3207.
> Hmmm, yes, the little matter of the downgrade attack.

You have that with the out-of-band negotiation case too though.

1. Try the TLS port.


2. ???

   If you connect to the non-TLS port you've just been downgraded,
   possibly not on purpose.  Or maybe the client will then try StartTLS
   and give up if the server won't.

   If the client falls back on not using TLS at all then you have a

Every IM and e-mail client I've used has the option to not require TLS.
That means they can be configured to fall back on not using TLS at all.
Worse, there's usually a checkbox for using TLS as opposed to a checkbox
for being insecure -- as a result, regardless of what the default is for
that checkbox the user is likely to check it off if they run into any

> It's a decision that ends up in the hands of the admin anyway.
> Admins are already maintaining the ACLs on their firewall.


> What are the advantages of running different versions of a protocol
> (having radically different security properties) on the same vs.
> different TCP ports?
> As I see it, running on different ports has some advantages:
> * Developers don't have to implement and test protocol support for
> some negotiation scheme.
> * Developers don't have to code support for configuration

When was the last time you saw a major IM or e-mail client that didn't
let you toggle TLS?  I can't remember when I last saw such a thing.

If such an app gives you that toggle it's because the developers were
willing to deal with the complexity of negotiation (whether starttls or
not) and configuration (that toggle is it).

> * Admins don't have to learn more configuration, site security
> doesn't depend as much on the perfection of

If you're going to use TLS chances are you'll be depending at least on
server certs, and at least a small PKI or pre-shared self-signed certs
or client-side SSH-style leap-of-faith.  The PKI approach -> lots of
admin (TA deployment, CA cert signing procedures, ...).  Making sure
that servers require TLS, whether StartTLS or otherwise, is not much

> I think a secure-only port number is the superior solution for many
> reasons. The ability to reliably block insecure connections based on
> looking only at the TCP/IP header is a powerful thing.

You still have to be sure that the client and server will actually, you
know, run TLS.

The only benefit of a "secure-only port number" is that you don't have
to make sure that the server requires TLS -- chances are near 100% it
just won't work if it doesn't, in which case the problem is self-
correcting (user files ticket, admins fix the problem).