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

Marsh Ray <> Tue, 09 November 2010 17:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D94443A6A26; Tue, 9 Nov 2010 09:50:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1KcFdg9Qi528; Tue, 9 Nov 2010 09:50:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 342613A69E2; Tue, 9 Nov 2010 09:50:56 -0800 (PST)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1PFsLo-0003d1-6A; Tue, 09 Nov 2010 17:51:20 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 9B9EA6019; Tue, 9 Nov 2010 17:51:18 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX193XYb3JwpGA3cE6sna/b53ICa861Y0fME=
Message-ID: <>
Date: Tue, 09 Nov 2010 11:51:18 -0600
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Thunderbird/3.0.10
MIME-Version: 1.0
To: Nicolas Williams <>
Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)
References: <> <p06240843c8fd6c508084@[]> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 12 Nov 2010 08:06:55 -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: Tue, 09 Nov 2010 17:50:58 -0000

On 11/08/2010 09:50 PM, Nicolas Williams wrote:
> On Mon, Nov 08, 2010 at 07:46:57PM -0600, Marsh Ray wrote:
>> On 11/08/2010 04:10 PM, Nicolas Williams wrote:
>>> It's not always the case that you have a trust path to a
>>> server,
>> Why not? Or, rather, isn't that a reasonable prerequisite for security?
> Because not every pair of communicating systems do so as part of a
> corporate network with well-staffed IT departments complete with PKIs,
> bridge PKIs, Kerberos, and other trust path mechanisms, with all hosts
> pre-registered, and so on.

Quite often, those are the places that have hardest time getting systems 
to interop.

> Usability is part of the security equation.  If secure applications are
> unusable, don't be surprised when users don't use them.

+1 that's absolutely true in reality.

However, doesn't there need to be

> SSH has been so successful in large part because leap-of-faith works
> rather well -- it has a very small window of vulnerability, a very big
> vulnerability, yes, and requiring persistent storage, true, but
> difficult to exploit without users eventually noticing.

I know I read a study somewhere of what users (a university setting I 
think) typically did when presented with the "WARNING: REMOTE HOST 
IDENTIFICATION HAS CHANGED!...Are you sure you want to continue 
connecting (yes/no)?" question. I think the results were pretty dismal.

>> In that sense, egress rules on client-based firewalls could be as
>> important as the inbound connections on the server side.
> So what you're proposing is that we require TLS on all the time, via raw
> TLS ports?

Not really, although it wouldn't be a bad idea to migrate in that 
direction. I'm more trying to ask a philosophical question.

We know that the properties we expect of the "secure communications" we 
discuss in in this WG depend on authentication or authenticated 
encryption. Authentication is thus something of a prerequisite for the 
security, unless we have justification to rule out the possibility of an 
active attacker. Although there are many scenarios in practice where 
active attacks are more difficult, any general-purpose protocol will 
have to resist them effectively.

So, except in cases where explictly unauthenticated endpoints are 
involved, isn't it reasonable that for WG discussions to presume that a 
security protocol will be building upon some form of trust framework?

Or is there a new world happening where we're retreating from that 
principle and we now expect systems to somehow bootstrap their own 
security out-of-the-box or not get used at all?

- Marsh