From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: A couple of questions and concerns about Emacs network security Date: Fri, 06 Jul 2018 09:29:59 +0300 Message-ID: <83bmbknafs.fsf@gnu.org> References: <20180705093346.071e6970@jabberwock.cb.piermont.com> <83wou9n66t.fsf@gnu.org> <20180705112920.076265d5@jabberwock.cb.piermont.com> <83r2khms1j.fsf@gnu.org> <20180705164500.0bde16cd@jabberwock.cb.piermont.com> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1530858540 4397 195.159.176.226 (6 Jul 2018 06:29:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Jul 2018 06:29:00 +0000 (UTC) Cc: larsi@gnus.org, eggert@cs.ucla.edu, wyuenho@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: "Perry E. Metzger" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 06 08:28:55 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fbKEh-000139-Ap for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 08:28:55 +0200 Original-Received: from localhost ([::1]:55999 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbKGo-0002K5-Cs for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 02:31:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbKFt-0002Fb-55 for emacs-devel@gnu.org; Fri, 06 Jul 2018 02:30:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbKFp-00069n-FB for emacs-devel@gnu.org; Fri, 06 Jul 2018 02:30:09 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42866) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbKFp-00069R-Bm; Fri, 06 Jul 2018 02:30:05 -0400 Original-Received: from [176.228.60.248] (port=4986 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fbKFi-0007EO-AC; Fri, 06 Jul 2018 02:29:58 -0400 In-reply-to: <20180705164500.0bde16cd@jabberwock.cb.piermont.com> (perry@piermont.com) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:226985 Archived-At: > Date: Thu, 5 Jul 2018 16:45:00 -0400 > From: "Perry E. Metzger" > Cc: larsi@gnus.org, eggert@cs.ucla.edu, wyuenho@gmail.com, > emacs-devel@gnu.org, rms@gnu.org > > > People die on the roads every day, but restricting free movement due > > to that somehow doesn't sound right to me. > > No one's freedom is restricted by providing sane default security in > anything that can be used as a browser. Restricting free movement on roads doesn't necessarily restrict the freedom, it usually is a rather large annoyance. Likewise excess security: you get annoying prompts, popups and tooltips all over the place. I'm saying that the annoyance should be proportionate to the dangers, and that we should find the fine balance where they are proportionate. > You're not removing the ability of users to reconfigure things any > way they want. They can turn off the security any time they > want. However, by setting sane defaults, you're making things work > reasonably so that, for example, thugs cannot intercept their > email. (Emacs is, after all, a mail reader for many of us, and we > would prefer that random sets of thugs with torture chambers _not_ > be able to intercept our IMAP connections by default by forging > certificates.) I think we should assume people generally know whether thugs with torture chambers might be after them. I see no reason to assume each and every Emacs user is in this situation, and I see no reason to annoy each and every Emacs user with alerts and prompts based on that assumption. As for "they can turn off" part: since the additions are almost all of them proposed for the 'medium' level of security, the only way of "turning off" is to go to 'low', which in Emacs means no security at all, and that makes even less sense to me. Which brings me to the main comment on everything that you wrote against my opinions: please read my comments and questions in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31946#89. Because that's the only/main thing that bothers me in the patches discussed in this and other related threads, and without reading that, your comments will generally miss the point. > Emacs even makes it easy to customize things. We're just giving > people reasonable defaults. We should do that, yes. I'm questioning whether the proposed defaults are "reasonable", that's all. > As I noted, RMS cares about this stuff enough that the front of every > single email he sends talks about state sponsored espionage on > citizens. Why would we not implement simple, sane things like setting > reasonable minimum keylengths for Diffie-Hellman to prevent known > downgrade attacks? See above: you are missing my point, because you haven't read my comments to the patches. > > > If people want to remove security on their own, that's their > > > business, but providing defaults that are not even as secure as > > > what Chrome or Firefox does is totally irresponsible. > > > > Emacs is not a Web browser, > > It is if you use it to browse the web. TLS is also used for a variety > of other things -- email, file transfer, etc. -- that Emacs does > pretty regularly for people. I'm saying that the defaults used by browsers are not necessarily correct for non-browser applications, including email and file transfer. Some of them might be appropriate, some might be less so. In any case, please note that the current proposals don't copy what the browsers do, they add a lot of tests the browsers don't (yet) do, at least not by default. So arguments about what the browsers do are already not very convincing, as we explicitly consider to deviate from what they do (and rightfully so). > > I said nothing of the kind. I said that we need to have "the right > > amount" of security, that's all. Dumping all the possible > > protection methods on users without careful analysis of what is > > more and less important is a bad starting point. > > How the heck does obeying a site's explicit request for pinning or CT > "dump all the possible protection methods on users without careful > analysis"? If the site owners want to specify a particular key be > used, why is it up to us to not allow that? How does > requiring a minimum of 1024 bit keys, which is already way too low, > "dump all the possible protection methods on users without careful > analysis"? What careful analysis do you need to know that 256 bit DH > keys can be cracked even by amateurs? How does not allowing the use > of compromised cryptographic algorithms that are no longer accepted > for use by any browser or command line tool "dump all the possible > protection methods on users without careful analysis"? You are again missing the main point of my concerns. Please read the comments for the patches submitted in bug#31946. In a nutshell, I of course have nothing against each one of these measures, it's their sum total that is being put into the 'medium' level that bothers me.