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 17:30 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 634CF3A6A11 for <tls@core3.amsl.com>; Tue, 9 Nov 2010 09:30:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.092
X-Spam-Level:
X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
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 zYsSxBg1LKzB for <tls@core3.amsl.com>; Tue, 9 Nov 2010 09:30:33 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by core3.amsl.com (Postfix) with ESMTP id 32CAD3A6A12 for <tls@ietf.org>; Tue, 9 Nov 2010 09:30:32 -0800 (PST)
Received: from host86-154-167-163.range86-154.btcentralplus.com (HELO pc6) ([86.154.167.163]) by c2bthomr09.btconnect.com with SMTP id AQK23003; Tue, 09 Nov 2010 17:30:09 +0000 (GMT)
Message-ID: <00f501cb802b$24138840$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> <000501cb8001$a441f620$4001a8c0@gateway.2wire.net> <4CD97EA5.3000305@pobox.com>
Date: Tue, 09 Nov 2010 17:28:22 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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.0A0B0302.4CD98520.0181, actions=tag
X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4CD98522.0169, 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 17:30:34 -0000
----- Original Message ----- From: "Michael D'Errico" <mike-list@pobox.com> To: "t.petch" <ietfc@btconnect.com> Cc: <tls@ietf.org> Sent: Tuesday, November 09, 2010 6:02 PM > t.petch wrote: > > ----- Original Message ----- > > From: "Michael D'Errico" <mike-list@pobox.com> > > > > 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:-) > > Since you put a smiley at the end, it seems you're kidding, but just to be > clear.... > > - the most important requirement for protocols is integrity; I don't > know how to achieve that without TLS. > > - personally I also want privacy; not because I'm doing anything wrong, > but because it's-none-of-your-business what I buy online and what I > discuss with people through email, etc. I don't know how to achieve > this without encryption, thus TLS is an important tool. Michael Yes there was a smiley but there is also a serious point. I recently was involved in syslog over TLS and the RFC there explicitly calls it out. Diagnostic messages are good for diagnosing problems and so should be sent in the clear unless there is a reason to do otherwise (eg relating to security breaches, password misuse etc) and this is a general truth in operations (SNMP etc). Yes, I must have integrity, but privacy can be a real pain, stopping the determination of problems. And while my Pentium PC, and a Google teraflop server, can cope with most things (S/MIME as used by our ADs with Apples being the exception for me), network devices may be low-powered, more like an 8086 than a Pentium, so the cost of processing encryption can be significant. And, as a more general truth, the customers I work with are, for the most part, obsessed with encryption and think that, with that in place, all their security problems are solved. In that regard, the widespread use of phishing is excellent news, because it is finally opening their eyes, in a way I have not been able to, that unless you have authentication, you are a sucker for everything. Just another point of view, Tom Petch > - what do you mean by expensive? Google has published research results > showing that enabling TLS on their services required no more/different > hardware than they were using prior to switching on TLS. > > - also you have it backwards -- government should not be the one doing > things in secret! > > Mike
- [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