Re: The netsec thread

[Lars Ingebrigtsen]

Eli Zaretskii <address@hidden> writes:

> I'm firmly against removing existing documentation.  I simply don't
> believe it could ever do any harm.
>
> Specifically, regarding these issues, I don't like the paternalistic
> attitude "believe us we're doing the best-effort job to adhere to best
> practices".  Nothing and no one can assure we know best in every
> particular situation, so leaving the knobs for users to DTRT when we
> don't cannot be wrong.

I don't think it's a paternalistic attitude.  I just think these issues
aren't any more interesting to somebody reading the Emacs manual than any
other protocol issue.

In the Emacs manual, we don't discuss details of the SMTP or IMAP
protocols, and we don't give an exegesis on UTF-8.  But for TLS
connections, we currently have a lot of talk about RC4 and 3DES and the
like, and removing that isn't any more a matter of "trust us, we know
what we're doing" than not explaining in detail the difference between
EHLO and HELO in the SMTP protocol.

> I might agree to making the manual descriptions shorter, like
> mentioning the variables and pointing to the doc strings for their
> detailed descriptions.  But this is only acceptable if the text in the
> manual is little more than a copy of the doc string; otherwise we
> should enhance the doc strings to tell more.

The doc strings in the NSM are more detailed than anybody could wish
for, so pointing the Emacs manual readers to those is a good idea, I
think.  Here's the doc string for one of the about 20 checks:

(defun nsm-protocol-check--rsa-kx (host port status &optional settings)
  "Check for static RSA key exchange.

Static RSA key exchange methods do not offer perfect forward
secrecy, therefore, the security of a TLS session is only as
secure as the server's private key.  Due to TLS' use of RSA key
exchange to create a session key (the key negotiated between the
client and the server to encrypt traffic), if the server's
private key had been compromised, the attacker will be able to
decrypt any past TLS session recorded, as opposed to just one TLS
session if the key exchange was conducted via a key exchange
method that offers perfect forward secrecy, such as ephemeral
Diffie-Hellman key exchange.

By default, this check is only enabled when
`network-security-level' is set to `high' for compatibility
reasons.

Reference:

Sheffer, Holz, Saint-Andre (May 2015).  \"Recommendations for Secure
Use of Transport Layer Security (TLS) and Datagram Transport Layer
Security (DTLS)\", \"(4.1.  General Guidelines)\"
`https://tools.ietf.org/html/rfc7525\#section-4.1'"


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no