Re: A couple of questions and concerns about Emacs network security

[Eli Zaretskii]

> From: Noam Postavsky <address@hidden>
> Date: Sat, 23 Jun 2018 18:28:15 -0400
> Cc: Lars Magne Ingebrigtsen <address@hidden>, Paul Eggert <address@hidden>, 
>       Jimmy Yuen Ho Wong <address@hidden>, Emacs developers <address@hidden>
> 
> On 23 June 2018 at 02:40, Eli Zaretskii <address@hidden> 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?