Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)
"t.petch" <ietfc@btconnect.com> Tue, 09 November 2010 12:33 UTC
Return-Path: <ietfc@btconnect.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C573A69A4 for <tls@core3.amsl.com>; Tue, 9 Nov 2010 04:33:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.358
X-Spam-Level:
X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 3ezL+yrPYFsv for <tls@core3.amsl.com>; Tue, 9 Nov 2010 04:33:07 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by core3.amsl.com (Postfix) with ESMTP id B7ACB3A699A for <tls@ietf.org>; Tue, 9 Nov 2010 04:33:06 -0800 (PST)
Received: from host86-154-167-163.range86-154.btcentralplus.com (HELO pc6) ([86.154.167.163]) by c2bthomr14.btconnect.com with SMTP id AOV91657; Tue, 09 Nov 2010 12:33:05 +0000 (GMT)
Message-ID: <000501cb8001$a441f620$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Michael D'Errico <mike-list@pobox.com>
References: <4CD76B1B.5030308@ericsson.com> <4CD78027.6090004@pobox.com>
Date: Tue, 09 Nov 2010 12:02:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CD93F74.00A9, actions=tag
X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4CD93F81.00F2, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Cc: tls@ietf.org
Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2010 12:33:08 -0000
----- Original Message ----- From: "Michael D'Errico" <mike-list@pobox.com> To: "Magnus Westerlund" <magnus.westerlund@ericsson.com> Cc: "Paul Hoffman" <paul.hoffman@vpnc.org>; <tls@ietf.org>; "tsvwg" <tsvwg@ietf.org> Sent: Monday, November 08, 2010 5:44 AM Here's a radical idea for IANA -- STOP REGISTERING UNENCRYPTED PROTOCOLS! <tp> Michael Here's a better idea; stop registering encrypted protocols; they are expensive and damaging and practically noone needs them, just a few bankers, spies and governments:-) Of course, authentication is a very different matter, and should be mandatory in all procotols; and if encryption allows a bootstrap of authentication, then there is a case for encryption, otherwise not. Just a different perspective on the requirements for security:-) Tom Petch </tp> The days of unencrypted anything are nearing an end, so there should be only one port assigned that uses TLS. The day is coming when businesses will be forced to stop sending email that is unencrypted. Their privacy policies will demand it. SMTP will either get a don't_forward_this_ without_encryption option, or it will perish. Mike Magnus Westerlund wrote: > TLS experts, > > There currently a WG last call ongoing in on the IANA Procedures for the > Management of the Service Name and Transport Protocol Port Number > Registry update document. > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ > > A WG last call comment on this document was raised by Paul Hoffman: > http://www.ietf.org/mail-archive/web/tsvwg/current/msg10305.html > > 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. > > The downside of less restrictive port allocation rules is that the port > space will be consumed at a higher rate. Thus there is need to determine > what is the most suitable trade-off here. > > 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. > > Thanks > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- [TLS] Security concerns around co-locating TLS an… Magnus Westerlund
- Re: [TLS] Security concerns around co-locating TL… Michael D'Errico
- 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… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Geoffrey Keating
- 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… Richard Hartmann
- 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… 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… 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… 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… Bill Frantz
- Re: [TLS] Security concerns around co-locating TL… Steingruebl, Andy
- Re: [TLS] Security concerns around co-locating TL… t.petch
- Re: [TLS] Security concerns around co-locating TL… Michael D'Errico
- 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… Michael D'Errico
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Yoav Nir
- Re: [TLS] Security concerns around co-locating TL… Nelson B Bolyard
- Re: [TLS] Security concerns around co-locating TL… Peter Saint-Andre
- Re: [TLS] Security concerns around co-locating TL… Bill Frantz
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Michael D'Errico
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Juho Vähä-Herttua
- Re: [TLS] Security concerns around co-locating TL… Juho Vähä-Herttua
- 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… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Michael D'Errico
- Re: [TLS] Security concerns around co-locating TL… Nikos Mavrogiannopoulos
- Re: [TLS] Security concerns around co-locating TL… t.petch
- 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… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Michael D'Errico
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Chris Newman
- Re: [TLS] Security concerns around co-locating TL… Nico Williams
- Re: [TLS] Security concerns around co-locating TL… Matt DeMoss
- Re: [TLS] Security concerns around co-locating TL… Yoav Nir
- Re: [TLS] Security concerns around co-locating TL… Joe Touch