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: Sun, 24 Jun 2018 17:23:53 +0300 Message-ID: <83lgb4tg92.fsf@gnu.org> References: <83po0iuhs7.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1529850176 5938 195.159.176.226 (24 Jun 2018 14:22:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 24 Jun 2018 14:22:56 +0000 (UTC) Cc: larsi@gnus.org, eggert@cs.ucla.edu, wyuenho@gmail.com, emacs-devel@gnu.org To: Noam Postavsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 24 16:22:52 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 1fX5ul-0001RJ-1J for ged-emacs-devel@m.gmane.org; Sun, 24 Jun 2018 16:22:51 +0200 Original-Received: from localhost ([::1]:42103 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fX5wq-0001Qu-In for ged-emacs-devel@m.gmane.org; Sun, 24 Jun 2018 10:25:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45930) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fX5vu-0001Ql-Gc for emacs-devel@gnu.org; Sun, 24 Jun 2018 10:24:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fX5vp-0002ZP-To for emacs-devel@gnu.org; Sun, 24 Jun 2018 10:24:02 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54499) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fX5vp-0002ZC-Pf; Sun, 24 Jun 2018 10:23:57 -0400 Original-Received: from [176.228.60.248] (port=3219 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fX5vp-0002DM-42; Sun, 24 Jun 2018 10:23:57 -0400 In-reply-to: (message from Noam Postavsky on Sat, 23 Jun 2018 18:28:15 -0400) 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:226643 Archived-At: > From: Noam Postavsky > Date: Sat, 23 Jun 2018 18:28:15 -0400 > Cc: Lars Magne Ingebrigtsen , Paul Eggert , > Jimmy Yuen Ho Wong , Emacs developers > > On 23 June 2018 at 02:40, Eli Zaretskii wrote: > > >> Can we bump gnutls-min-prime-bits to 1024 on the release branch? > > > > No, I don't think so. Changing these settings needs a prolonged > > testing period to uncover any subtle problems with non-conforming > > servers that users must be able to access, and such testing is > > unlikely to happen on emacs-26 before the next bug-fix release. > > I'm not sure what testing would be needed: if the connection to a > server fails, the user sets the variable to the previous default. If too many users will have to reset to previous defaults, then what exactly did we accomplish, except annoying those users by having stuff not work OOTB? > Also, would this attack published in 2015 make a difference to the decision? > > https://weakdh.org/ > https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf > > The Logjam attack allows a man-in-the-middle attacker to downgrade > vulnerable TLS connections to 512-bit export-grade cryptography. > > RECOMMENDATIONS > > Server operators should disable DHE_EXPORT and configure DHE > ciphersuites to use primes of 2048 bits or larger. Browsers > and clients should raise the minimum accepted size for > Diffie-Hellman groups to at least 1024 bits in order to avoid > downgrade attacks when communicating with servers that still > use smaller groups. Primes of less than 1024 bits should not > be considered secure, even against an attacker with moderate > resources. Is this relevant to Emacs? Given the explanations by Lars here: http://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00736.html having the GnuTLS related values low is by design, so that NSM (and the users) could be in control of what is allowed, instead of silently failing connections at a low level. Am I missing something?