From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: Robert Pluim <rpluim@gmail.com>, Emacs-Devel devel <emacs-devel@gnu.org>
Subject: Re: The netsec thread
Date: Mon, 23 Jul 2018 01:12:15 +0100 [thread overview]
Message-ID: <CAKDRQS4Yhk+Lna7biynUfE3tOpEAinROvpRi=8Q_j4Ja+hrLow@mail.gmail.com> (raw)
In-Reply-To: <m3bmaz1ekz.fsf@gnus.org>
>> +** New function 'network-lookup-address-info'.
>> +This does IPv4 and/or IPv6 address lookups on hostnames.
>
> I'm assuming this will be removed again since we got the new getaddrinfo
> function?
>
Yep.
>> "List of CA bundle location filenames or a function returning said list.
>> +If a file path contains glob wildcards, they will be expanded.
>
> Hm. This seems like a good idea, but do we do this in other similar
> variables? And would perhaps regexp syntax make more sense than glob
> syntax?
>
Nah. This has already been looked at weeks ago, no need to
over-engineer it further as I believe most people will think of glob
when dealing with file paths. Besides, Emacs's regex isn't
particularly nice unless Dan elects to retrofit PCRE into Emacs :P
The reason I need glob is IGTF's fetch-crl will put ~100s CRL PEM
files into the file system, it's very cumbersome to specify them
1-by-1.
>> -;;;###autoload
>> -(defcustom gnutls-min-prime-bits 256
>> - ;; Several mail servers send fewer bits than the GnuTLS default.
>> - ;; Currently, 256 appears to be a reasonable choice (Bug#11267).
>> +(defcustom gnutls-min-prime-bits nil
>
> As I've said before, I don't think this makes much sense. But in any
> case, the variable is obsolescent (since GnuTLS has said so), so perhaps
> we should just mark it obsolete and tell people to use the priority
> string to control these things.
>
Sorry I got lost in that giant thread.
`gnutls_dh_set_prime_bits` is only deprecated on GnuTLS 3.1.7+. Are we
dropping support for all version < 3.1.7? I'd be super happy to do it
if that's the case and remove this var and the C code entirely.
>> -`low': Absolutely no checks are performed.
>> -`medium': This is the default level, should be reasonable for most usage.
>> -`high': This warns about additional things that many people would
>> -not find useful.
>> -`paranoid': On this level, the user is queried for most new connections.
>> +`low': Check for problems known before Edward Snowden.
>> +`medium': Default. Suitable for most circumstances.
>> +`high': Warns about additional issues not enabled in `medium' due to
>> +compatibility concerns.
>
> I don't think it makes much sense to talk about Snowden as if that's
> something people are meant to understand.
I'd be happy to, but I have no idea what 'low means anymore. In fact,
if you think about impact as a 2-dimensional variable as opposed to
this linear scale, you'd have a quadrant defined by "impact" and
"compatibility". Hi-impact-hi-compat should be enabled without
question, which roughly corresponds to 'low. Hi-impact-lo-compat and
Lo-impact-hi-compat do not exist as a concept in NSM ATM.
Lo-impact-lo-compat is 'paranoid? But what would be in it and why
bother?
> And, as I've said before,
> `paranoid' should stay.
>
Eli's use case has already been taken cared of by
`nsm-trust-local-network`. `paranoid has been aliased to `high for
backward compatibility.
Robert do you still object to removing the `paranoid level? I've
removed that prompt that askes for permission on every TLS connection
due to crying-wolf effect.
If there isn't an objection from people who've found use for it, I'd
really like to try without 'paranoid on master later before declaring
it insufficient.
> Calling protocol checks "TLS" checks isn't future proof. We've
> already had one politically motivated name change (from SSL to TLS)
> and we may have another. And besides, many of these checks are also
> valid for SSL, so it's just confusing.
>
The TLS working group wasn't even willing to call TLS 1.3[1] TLS 2.0
even when it's a major departure from it. I doubt we need to worry
about extra work to change a name. YAGNI applies.
[1]: https://www.ietf.org/mail-archive/web/tls/current/msg20938.html
> Call them `nsm-protocol-check' and stick the -- back in. And having
> the entire function name instead of just the bit after "check--" makes
> it more tedious for people to remove/add their own functions.
>
`nsm-tls-checks` is already a defcustom. It's super easy to add and
remove a function. You can defun whatever name you want and add to it,
and click [-] to remove. Using name mangling magic to fish out a check
function makes defcustom super-awkward, and AFAIK, no other emacs core
setting does it this way.
>> +(defun nsm-should-check (host)
>> + "Determines whether NSM should check for TLS problems for HOST.
>> +
>> +If `nsm-trust-local-network' is or returns non-nil, and if the
>> +host address is a localhost address, a machine address, a direct
>> +link or a private network address, this function returns
>> +nil. Non-nil otherwise."
>
> What do you mean by "machine address"? The MAC address? If you mean
> IP address, it's perfectly valid to have TLS on a non-named IP
> address. 1.0.0.1 does that for DNS over HTTPS last I heard, and
> that's definitely a service you should verify, well, everything on.
>
I mean 0.0.0.0/8. I'm not sure what the proper name is or if I even
need to deal with it. What do you think?
>
>> +(defun nsm-tls-check-rsa-kx (host port status &optional settings)
>
> In Emacs functions we try to avoid abbreviations unless they're very
> common. kx is too obscure; say key-exchange instead.
>
Will do.
>> +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'"
>
> [...]
>
>> +GnuTLS authors (2018). \"GnuTLS Manual 4.3.3 Anonymous
>> +authentication\",
>> +`https://www.gnutls.org/manual/gnutls.html\#Anonymous-authentication'"
>
> Heh heh. I like all the references, but perhaps it's a lot of URLs to
> keep updated? Perhaps not?
>
These provide justification for the checks and make it easy for
everyone to fact-check my rationale. Most of them are just RFC URLs,
they never fail to resolve.
>> + (let* ((accept-choices '((?a "always" "Accept this certificate this session and for all future sessions.")
>> + (?s "session only" "Accept this certificate this session only.")
>> + (?n "no" "Refuse to use this certificate, and close the connection.")
>> + (?d "details" "See certificate details")))
>> + (details-choices '((?b "backward page" "See previous page")
>> + (?f "forward page" "See next page")
>> + (?n "next" "Next certificate")
>> + (?p "previous" "Previous certificate")
>> + (?q "quit" "Quit details view")))
>
> See previous messages about the UI.
>
Will update that later.
Thanks for reviewing!
next prev parent reply other threads:[~2018-07-23 0:12 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-20 11:33 The netsec thread Lars Ingebrigtsen
2018-07-20 12:24 ` Eli Zaretskii
2018-07-20 12:33 ` Lars Ingebrigtsen
2018-07-20 12:36 ` Lars Ingebrigtsen
2018-07-20 12:41 ` Eli Zaretskii
2018-07-20 12:45 ` Lars Ingebrigtsen
2018-07-23 1:52 ` Jimmy Yuen Ho Wong
2018-07-23 1:55 ` Brett Gilio
2018-07-23 2:32 ` Eli Zaretskii
2018-07-23 12:46 ` Lars Ingebrigtsen
2018-07-23 13:31 ` Andy Moreton
2018-07-23 14:43 ` Jimmy Yuen Ho Wong
2018-07-23 14:46 ` Andy Moreton
2018-07-23 15:48 ` Lars Ingebrigtsen
2018-07-23 16:54 ` Andy Moreton
2018-07-23 19:34 ` Andy Moreton
2018-07-24 8:24 ` Lars Ingebrigtsen
2018-07-24 9:34 ` Andy Moreton
2018-07-24 11:54 ` Andy Moreton
2018-07-24 12:09 ` Noam Postavsky
2018-07-24 13:59 ` Jimmy Yuen Ho Wong
2018-07-24 14:11 ` Lars Ingebrigtsen
2018-07-24 18:21 ` Andy Moreton
2019-07-28 18:18 ` Lars Ingebrigtsen
2019-07-28 18:27 ` Eli Zaretskii
2019-07-28 18:33 ` Lars Ingebrigtsen
2019-07-28 18:34 ` Lars Ingebrigtsen
2019-07-28 19:08 ` Lars Ingebrigtsen
2019-07-28 19:12 ` Eli Zaretskii
2019-07-29 11:12 ` Lars Ingebrigtsen
2019-07-29 7:50 ` Robert Pluim
2019-07-29 8:11 ` Robert Pluim
2019-07-29 11:18 ` Lars Ingebrigtsen
2019-07-29 11:14 ` Lars Ingebrigtsen
2019-07-29 14:02 ` Robert Pluim
2019-07-30 11:30 ` Lars Ingebrigtsen
2019-07-30 13:12 ` Robert Pluim
2019-07-30 13:32 ` Lars Ingebrigtsen
2019-07-30 15:05 ` Robert Pluim
2019-08-07 12:27 ` Robert Pluim
2019-08-07 18:41 ` Lars Ingebrigtsen
2019-08-23 2:58 ` Lars Ingebrigtsen
2019-08-23 8:19 ` Paul Eggert
2019-08-23 8:52 ` Lars Ingebrigtsen
2019-08-23 9:01 ` Lars Ingebrigtsen
2019-08-23 19:03 ` Paul Eggert
2019-08-25 5:33 ` Lars Ingebrigtsen
2019-09-03 9:49 ` Robert Pluim
2019-09-03 13:30 ` Paul Eggert
2019-09-03 15:37 ` Robert Pluim
2019-09-03 19:20 ` Paul Eggert
2019-09-03 20:02 ` Robert Pluim
2019-09-04 13:12 ` Lars Ingebrigtsen
2019-09-04 19:34 ` Robert Pluim
2019-09-04 21:35 ` Paul Eggert
2019-09-04 21:54 ` Robert Pluim
2019-09-05 12:12 ` Robert Pluim
2019-09-05 18:50 ` Paul Eggert
2019-09-05 19:34 ` Robert Pluim
2019-09-04 13:10 ` Lars Ingebrigtsen
2019-08-23 9:09 ` Eli Zaretskii
2019-08-23 9:40 ` Robert Pluim
2019-08-23 12:18 ` Eli Zaretskii
2019-08-23 12:39 ` Robert Pluim
2019-08-23 13:03 ` Eli Zaretskii
2019-08-23 13:20 ` Robert Pluim
2019-08-23 14:15 ` Eli Zaretskii
2019-08-23 14:27 ` Robert Pluim
2019-08-23 14:40 ` Eli Zaretskii
2019-08-23 14:58 ` Robert Pluim
2019-08-23 15:04 ` Eli Zaretskii
2019-08-23 9:58 ` Lars Ingebrigtsen
2019-08-23 12:43 ` Eli Zaretskii
2019-08-25 5:32 ` Lars Ingebrigtsen
2019-08-25 22:29 ` Richard Stallman
2019-08-26 4:16 ` Lars Ingebrigtsen
2018-07-23 15:22 ` Eli Zaretskii
2018-07-22 14:48 ` Lars Ingebrigtsen
2018-07-23 0:12 ` Jimmy Yuen Ho Wong [this message]
2018-07-23 8:17 ` Robert Pluim
2018-07-23 14:58 ` Jimmy Yuen Ho Wong
2018-07-23 15:06 ` Robert Pluim
2018-07-23 15:37 ` Lars Ingebrigtsen
2018-07-23 15:51 ` Jimmy Yuen Ho Wong
2018-07-23 16:06 ` Noam Postavsky
2018-07-23 16:11 ` Lars Ingebrigtsen
2018-07-23 15:04 ` Eli Zaretskii
2018-07-23 15:24 ` Jimmy Yuen Ho Wong
2018-07-23 15:34 ` Robert Pluim
2018-07-23 16:38 ` Jimmy Yuen Ho Wong
2018-07-23 17:25 ` Robert Pluim
2018-07-23 17:54 ` Eli Zaretskii
2018-07-23 20:51 ` Robert Pluim
2018-07-23 9:55 ` Lars Ingebrigtsen
2018-07-23 15:22 ` Jimmy Yuen Ho Wong
2018-07-23 15:46 ` Lars Ingebrigtsen
2018-07-23 15:48 ` Jimmy Yuen Ho Wong
2018-07-23 15:49 ` Noam Postavsky
2018-07-23 16:13 ` Lars Ingebrigtsen
2018-07-23 10:23 ` Andreas Schwab
2018-07-20 12:55 ` Jimmy Yuen Ho Wong
2018-07-20 12:59 ` Jimmy Yuen Ho Wong
2018-07-20 13:00 ` Lars Ingebrigtsen
2018-07-20 13:11 ` Jimmy Yuen Ho Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKDRQS4Yhk+Lna7biynUfE3tOpEAinROvpRi=8Q_j4Ja+hrLow@mail.gmail.com' \
--to=wyuenho@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
--cc=rpluim@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.