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

[Eli Zaretskii]

> Date: Thu, 5 Jul 2018 16:45:00 -0400
> From: "Perry E. Metzger" <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden,
>  address@hidden, address@hidden
> 
> > 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.