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> Mon, 08 November 2010 22:12 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 4ADED3A6980; Mon, 8 Nov 2010 14:12:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.412
X-Spam-Level:
X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.186, 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 diuYGY3FoCVo; Mon, 8 Nov 2010 14:11:53 -0800 (PST)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 8E5243A68AF; Mon, 8 Nov 2010 14:11:52 -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 oA8MCBpX026405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Nov 2010 22:12:12 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 oA8HmKHW002502; Mon, 8 Nov 2010 22:12:09 GMT
Received: from abhmt018.oracle.com by acsmt354.oracle.com with ESMTP id 758791111289254221; Mon, 08 Nov 2010 14:10:21 -0800
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Nov 2010 14:10:21 -0800
Date: Mon, 08 Nov 2010 16:10:16 -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: <20101108221016.GT6536@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4CD86FC4.4070308@extendedsubset.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Mailman-Approved-At: Tue, 09 Nov 2010 00:05:46 -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: Mon, 08 Nov 2010 22:12:02 -0000

On Mon, Nov 08, 2010 at 03:46:44PM -0600, Marsh Ray wrote:
> On 11/08/2010 02:24 PM, Nicolas Williams wrote:
> 
> >>* 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.
> 
> It's awful, isn't it?

I'm not sure.  It's not always the case that you have a trust path to a
server, so if we force TLS on all the time then we're also training
users to do SSH leap-of-faith (or worse, if the client isn't very good).
Now, SSH leap-of-faith is actually a pretty good solution, so maybe
that's OK.  But we'd still be training users to keep clicking "OK [give
all my money to the bad guy]".

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

Nico
--