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

Nicolas Williams <Nicolas.Williams@oracle.com> Tue, 09 November 2010 18:11 UTC

Return-Path: <Nicolas.Williams@oracle.com>
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 E691A3A6A31; Tue, 9 Nov 2010 10:11:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.46
X-Spam-Level:
X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 t3cHGT7r1ArG; Tue, 9 Nov 2010 10:11:04 -0800 (PST)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E6AFE28C127; Tue, 9 Nov 2010 10:11:03 -0800 (PST)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oA9IBQ8S024469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Nov 2010 18:11:27 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oA9AZGbk016133; Tue, 9 Nov 2010 18:11:24 GMT
Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 762015051289326279; Tue, 09 Nov 2010 10:11:19 -0800
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Nov 2010 10:11:19 -0800
Date: Tue, 9 Nov 2010 12:11:14 -0600
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Marsh Ray <marsh@extendedsubset.com>
Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)
Message-ID: <20101109181114.GE6536@oracle.com>
References: <E1PFKZ3-0002jp-Bu@login01.fos.auckland.ac.nz> <p06240843c8fd6c508084@[130.129.55.1]> <4CD83312.5060000@extendedsubset.com> <20101108202407.GO6536@oracle.com> <4CD86FC4.4070308@extendedsubset.com> <20101108221016.GT6536@oracle.com> <4CD8A811.1080801@extendedsubset.com> <20101109035040.GA6536@oracle.com> <4CD98A16.4070004@extendedsubset.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4CD98A16.4070004@extendedsubset.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Mailman-Approved-At: Fri, 12 Nov 2010 08:06:55 -0800
Cc: tls@ietf.org, Paul Hoffman <paul.hoffman@vpnc.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: Tue, 09 Nov 2010 18:11:15 -0000

On Tue, Nov 09, 2010 at 11:51:18AM -0600, Marsh Ray wrote:
> On 11/08/2010 09:50 PM, Nicolas Williams wrote:
> 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.

For small deployments (say, home networks) the user can know that the
keys shouldn't have changed.  For larger-but-still-smallish deployments
this is a problem, and for sufficiently large deployments it's not a
problem at all because large organizations should be using GSS/Kerberos,
PKI, or else should be distributing known_hosts files, preferably via
DNSSEC.

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

Philosophy is fine, but the original poster proposed something concrete
(that we drop StartTLS and just always use raw TLS); we should have an
answer to that.  Mine is that the arguments against StartTLS are weak,
and the arguments for always using raw TLS are also weak.  I'm
unconvinced by the OP's and others' arguments against StartTLS.

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

Yes.  But don't go to extremes, don't rule out leap-of-faith.  I'd be
very cross if I had to deploy a PKI in my house :)

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

Yes, but what does that have to do with the OP's post?

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

Bootstrapping security is a good thing.  Ideally we'd all have
smartcards and we could use those to bootstrap joining systems to a PKI,
Kerberos realm, etcetera, but often all we have is passwords, and
sometimes not even that.  For small scale deployments leap-of-faith
works wonders.  For larger scale deployments you can rely on capable IT
departments to pre-load trust anchors, etcetera.

Nico
--