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 03:52 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 0F66A3A695E; Mon, 8 Nov 2010 19:52:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.454
X-Spam-Level:
X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.144, 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 G9ecV0zBeyiB; Mon, 8 Nov 2010 19:51:58 -0800 (PST)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id BA2363A6A17; Mon, 8 Nov 2010 19:51:35 -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 oA93pqVd001308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Nov 2010 03:51:54 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oA93pp7t022584; Tue, 9 Nov 2010 03:51:51 GMT
Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 761030971289274645; Mon, 08 Nov 2010 19:50:45 -0800
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Nov 2010 19:50:45 -0800
Date: Mon, 08 Nov 2010 21:50:40 -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: <20101109035040.GA6536@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4CD8A811.1080801@extendedsubset.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Mailman-Approved-At: Tue, 09 Nov 2010 00:06:07 -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 03:52:09 -0000

On Mon, Nov 08, 2010 at 07:46:57PM -0600, Marsh Ray wrote:
> 
> Sorry Nico, this is not so much a reply to you specifically as I
> started thinking and writing about the SSH
> leap-of-faith/trust-on-first-use model.
> 
> 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.

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

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.

> Aside from that, I think the thing that bugs me about ToFU is the
> definition of the term "first use".

Me too.  Leap of faith is not for all.  But clearly it has its place,
and that's not yet the ash heap of history.

> >>I.e., the default failure mode is secure, rather than insecure.
> >
> >Only on the server side.  If the firewall is not close to the client
> >then the client can still fallback on insecure connections.  In many
> >cases it's the client that matters most.
> 
> Good point.
> 
> 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?

Nico
--