From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Jimmy Yuen Ho Wong Newsgroups: gmane.emacs.devel Subject: Re: The netsec thread Date: Mon, 23 Jul 2018 01:12:15 +0100 Message-ID: References: <83bmb214ez.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1532304641 31541 195.159.176.226 (23 Jul 2018 00:10:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 23 Jul 2018 00:10:41 +0000 (UTC) Cc: Robert Pluim , Emacs-Devel devel To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 23 02:10:37 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 1fhOQu-00083n-W3 for ged-emacs-devel@m.gmane.org; Mon, 23 Jul 2018 02:10:37 +0200 Original-Received: from localhost ([::1]:58312 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fhOT0-0005hB-1P for ged-emacs-devel@m.gmane.org; Sun, 22 Jul 2018 20:12:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fhOSs-0005gs-GA for emacs-devel@gnu.org; Sun, 22 Jul 2018 20:12:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fhOSq-00064k-MV for emacs-devel@gnu.org; Sun, 22 Jul 2018 20:12:38 -0400 Original-Received: from mail-io0-x233.google.com ([2607:f8b0:4001:c06::233]:45421) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fhOSq-00064V-F1 for emacs-devel@gnu.org; Sun, 22 Jul 2018 20:12:36 -0400 Original-Received: by mail-io0-x233.google.com with SMTP id k16-v6so4383197iom.12 for ; Sun, 22 Jul 2018 17:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0J+3n4+kbWpNsrLBIzpB7hE/Joak2Netguv49DGGWJ4=; b=taU0+7slK3mPVWNAgZiT9o8KZyH+7vNriHVsGLprnuUAGcGws8/V/yKPNumeyikIF1 kS8y2NFcO2E3QPMQx+vpODJrpoCmsKrh5kgiU59eGCYZmryyZgXoER2pIeLVe9K8E5Jn tc47RA/+KIYEnSrWWoZxacXr/BkZ8dZtFhE/T79QwmblfAIJoO79s+zAIu1B/AkEQQGb 8M0wEFy4mGGX0IGp3H/9Y3FP+Y+E58IZhFBCtzq1ajnAzul7s3YmAnbYVUcU9FjjQb68 88hdhCCRKzhk6vgjBGfBRKjdKuw18xA/uVFgXjnHFb2Y/onc1t4g/qkxrGKtcwyx27j9 OYzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0J+3n4+kbWpNsrLBIzpB7hE/Joak2Netguv49DGGWJ4=; b=npL5k3rv1LB2miMnxpGr2mvHp8y9Ivjw2jfr63/N56hb2ztAx43JH7YWRspWwYr2f5 h+axLw7njSdyZWfJpb8/eCWYfR/178uYQLKlaUkEYqbaSA6dSYowYvH8IBquPMyUzCzC VoBy0XSsTi+wnVb+CysILmpVhYj9jQFCmzKVnYCQ+ZpKNeP/9uUmklA5RimSbI8aKXyP e97TerRcBudxOLYWIOF4BtWnd4y/26jB4UWMXG2rEWLCNlbpCXTg+Mg+GTOaXBetQgiT ihY+XmcldE0V/BjE21nfOsPxKyjtKJbuBRBoPNPmwpqk6pY85EAIJ5/jiCMj0/JZhA+S BMqw== X-Gm-Message-State: AOUpUlH5rVLIU4LlyTgV4w62QHSSZ4g3a8q3BOs2lTcDPsssUhprd5aG hAHXpIkSaLpBLOlRu1kZiyVxG9ypi9ZsE8sUwxk= X-Google-Smtp-Source: AAOMgpfAcwTpIWQgFR2z3H/JvyOFYYbKxok604l8fGLxFAHE86e+nytFfYBctRnKV2EzWeTVfIVoo4BCIU4VAJzi7iM= X-Received: by 2002:a5e:9812:: with SMTP id s18-v6mr8272714ioj.117.1532304755798; Sun, 22 Jul 2018 17:12:35 -0700 (PDT) Original-Received: by 2002:a02:985d:0:0:0:0:0 with HTTP; Sun, 22 Jul 2018 17:12:15 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c06::233 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:227694 Archived-At: >> +** 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!