Re: Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)
Geoffrey Keating <geoffk@geoffk.org> Mon, 08 November 2010 19:40 UTC
Return-Path: <geoffk@geoffk.org>
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 804E03A6852; Mon, 8 Nov 2010 11:40:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 LyZqSz0SC4xi; Mon, 8 Nov 2010 11:40:17 -0800 (PST)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by core3.amsl.com (Postfix) with ESMTP id 376AC3A6879; Mon, 8 Nov 2010 11:40:17 -0800 (PST)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 2644533D178; Mon, 8 Nov 2010 19:40:30 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Subject: Re: Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)
References: <4CD76B1B.5030308@ericsson.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Mon, 08 Nov 2010 11:40:29 -0800
In-Reply-To: <4CD76B1B.5030308@ericsson.com>
Message-ID: <m27hgnk3iq.fsf@localhost.localdomain>
Lines: 46
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailman-Approved-At: Tue, 09 Nov 2010 00:05:46 -0800
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, tls@ietf.org, tsvwg <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 19:40:18 -0000
Magnus Westerlund <magnus.westerlund@ericsson.com> writes: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ .. > My summary of that comment is that STARTTLS for SMTP (RFC 3207) has > shown to have some security issues, be complexer to implement than using > two ports and thus less popular. Thus the registration rules should be > less restrictive in assigning an additional port for TLS version of > services/applications/protocols. ... > Clearly if the security issues are serious when one multiplex TLS and > non-secured version of the protocol on the same port we must allow such > port allocations. However if the issues are minor and the primarily > issue is implementation complexity then saving the limited port space is > probably more important. > > Your input into these questions would be very appreciated. There are also security issues when two ports are used: how can an application choose which port to communicate over? Paul mentions the list of security issues in RFC 3207, but each of these corresponds to a similar issue in a two-port solution. Eventually the RFC (and similar specifications of other protocols) comes down to "The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependent, and is beyond the scope of this document." and in practise this leads to at least one, and sometimes more, of these: 1. Implementations which do not interoperate, because one requires security and the other does not implement it, 2. Automatically falling back to insecure communications when secure communications cannot be achieved, even if this is due to an attacker's denial-of-service, or 3. Asking the user questions that the user does not understand or for which the user cannot know the answer ("Is example.com supposed to have secure email?"). So, I think there are very limited additional concerns for a single-port approach over a two-port approach, but there are significant problems with both, and if implementation complexity and interoperability is a concern it could and probably should be addressed by specifying that TLS is always used.
- Security concerns around co-locating TLS and non-… Magnus Westerlund
- Re: [TLS] Security concerns around co-locating TL… Paul Hoffman
- Re: [TLS] Security concerns around co-locating TL… Magnus Westerlund
- Re: [TLS] Security concerns around co-locating TL… Michael D'Errico
- Re: Security concerns around co-locating TLS and … Geoffrey Keating
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Richard Hartmann
- Re: [TLS] Security concerns around co-locating TL… Richard Hartmann
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Bill Frantz
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… t.petch
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Matt DeMoss
- Re: [TLS] Security concerns around co-locating TL… Nico Williams
- Re: [TLS] Security concerns around co-locating TL… Chris Newman
- Re: [TLS] Security concerns around co-locating TL… Yoav Nir
- Re: [TLS] Security concerns around co-locating TL… Joe Touch