From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Perry E. Metzger" Newsgroups: gmane.emacs.devel Subject: Re: Bug#766395: emacs/gnus: Uses s_client to for SSL. Date: Fri, 24 Oct 2014 20:42:02 -0400 Message-ID: <20141024204202.276dbb1f@jabberwock.cb.piermont.com> References: <20141022193441.GA11872@roeckx.be> <87zjcnj2k6.fsf@trouble.defaultvalue.org> <87mw8mzmxj.fsf@mid.deneb.enyo.de> <20141023143702.3897e618@jabberwock.cb.piermont.com> <8761fazkx7.fsf@mid.deneb.enyo.de> <20141023145721.12ed0820@jabberwock.cb.piermont.com> <87vbnay5lf.fsf@mid.deneb.enyo.de> <20141023154223.45f2c9eb@jabberwock.cb.piermont.com> <874muuihjh.fsf@uwakimon.sk.tsukuba.ac.jp> <20141023230048.13f8234a@jabberwock.cb.piermont.com> <87wq7pgpif.fsf@uwakimon.sk.tsukuba.ac.jp> <20141024171421.78720abe@jabberwock.cb.piermont.com> <87r3xxgmx2.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1414197754 25970 80.91.229.3 (25 Oct 2014 00:42:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Oct 2014 00:42:34 +0000 (UTC) Cc: Florian Weimer , rms@gnu.org, kurt@roeckx.be, Rob Browning , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 25 02:42:26 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XhpR4-0004PM-0t for ged-emacs-devel@m.gmane.org; Sat, 25 Oct 2014 02:42:26 +0200 Original-Received: from localhost ([::1]:51420 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhpR3-00047p-GU for ged-emacs-devel@m.gmane.org; Fri, 24 Oct 2014 20:42:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhpQl-00047h-D4 for emacs-devel@gnu.org; Fri, 24 Oct 2014 20:42:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XhpQh-0004zP-2N for emacs-devel@gnu.org; Fri, 24 Oct 2014 20:42:07 -0400 Original-Received: from hacklheber.piermont.com ([166.84.7.14]:48047) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhpQg-0004zI-VO; Fri, 24 Oct 2014 20:42:03 -0400 Original-Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id 7AC0D1438; Fri, 24 Oct 2014 20:42:02 -0400 (EDT) Original-Received: from jabberwock.cb.piermont.com (jabberwock.cb.piermont.com [10.160.2.107]) by snark.cb.piermont.com (Postfix) with ESMTP id 4B4A62DFD09; Fri, 24 Oct 2014 20:42:02 -0400 (EDT) In-Reply-To: <87r3xxgmx2.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; x86_64-apple-darwin14.0.0) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 166.84.7.14 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175801 Archived-At: On Sat, 25 Oct 2014 06:47:37 +0900 "Stephen J. Turnbull" wrote: > It's possible that the inconvenience is small. Your anecdote about > P25 radios suggests that in that case in fact it was, but that can > only be determined by finding out whether organizations different in > many ways are the same in that dimension. On the other hand, it is > a fact that people have died (and to this day are dying in Japan) > because of lack of compatibility between communication systems among > cooperating organizations such as fire and police. It's possible > that fallback-to-compatible capability did matter and still does > matter. There are ways to provide compatibility without sacrificing security, however. Read our papers or our (redacted) recommendations to law enforcement if you wish. > I'm not going to attempt to deny the importance of security, the > lack of information and training in use of optional security > features among users, or the rapid escalation of frequency and > power of attacks. Nevertheless, advocating extreme security policy > is unlikely to achieve the goal of extreme security in the current > environment, and I believe that a more balanced approach can do > better. I think that removing SSL 3.0 support is not an "extreme measure" and leaving it in isn't "balanced" at this point. TLS 1.0 has been around for a very long time. If you want to argue that removing TLS 1.0 and 1.1 support is a bad idea since support has only become 100% universal in the last several years, you have a case to make -- perhaps it should be another few years until those are deprecated. Then again, I never suggested removing them right now. If, on the other hand, you want to argue that getting rid of SSL 3.0 is a problem at this point, then you are arguing de facto that bad protocols can *never* be removed, and that causing minor inconvenience to a handful of users is far more important than security. Perry -- Perry E. Metzger perry@piermont.com