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:16 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 A5C893A6980; Mon, 8 Nov 2010 14:16:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.425
X-Spam-Level:
X-Spam-Status: No, score=-6.425 tagged_above=-999 required=5 tests=[AWL=0.173, 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 4CkI82CKDE5B; Mon, 8 Nov 2010 14:16:57 -0800 (PST)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A32E23A68AF; Mon, 8 Nov 2010 14:16:57 -0800 (PST)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oA8MHIia004473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Nov 2010 22:17:19 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oA8MGBdh020011; Mon, 8 Nov 2010 22:17:18 GMT
Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 760383191289254590; Mon, 08 Nov 2010 14:16:30 -0800
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Nov 2010 14:16:30 -0800
Date: Mon, 08 Nov 2010 16:16:25 -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: <20101108221625.GU6536@oracle.com>
References: <E1PFKZ3-0002jp-Bu@login01.fos.auckland.ac.nz> <p06240843c8fd6c508084@[130.129.55.1]> <20101108201218.GN6536@oracle.com> <4CD872C5.2010007@extendedsubset.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4CD872C5.2010007@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:16:58 -0000

On Mon, Nov 08, 2010 at 03:59:33PM -0600, Marsh Ray wrote:
> On 11/08/2010 02:12 PM, Nicolas Williams wrote:
> >On Mon, Nov 08, 2010 at 05:07:42PM +0800, Paul Hoffman wrote:
> >
> >>"be complexer to implement than using two ports": See the state
> >>machine described in section 4 and its subsections in RFC 3207. That's
> >>much more complex than "OK, let's go".
> >
> >This is true.  Specifically it complicates the task of making the
> >security layer transparent to the application.  But really, not _that_
> >much.
> 
> Does it have implications for session resumption I wonder?

What, StartTLS?  I don't think so, not over raw TLS.

> Not so much for the protocol itself, but for what you get with the
> straightforward use of a normal TLS library.

Any implementation that attempts to make TLS transparent to the
application does have all sorts of issues.  You can't hide all TLS
details from the app, or the user for that matter.

> For example, if a developer let the TLS library handle the socket
> connections it seems like it could be smart enough to support
> resumption, but a STARTTLS-based protocol would seem to prevent
> this. In cases where the app code is just passing buffers to the TLS
> library, the TLS stack may not even know the hostname at the time of
> the Hello message exchange.

Clearly a raw StartTLS approach requires that the app pass in all the
parameters that the TLS library might have been able to obtain by itself
in a raw TLS case.

> It's probably not a big deal for most mail protocols, but it might
> make a perceptible difference for a user of IMAP.

Shouldn't be.