From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= Newsgroups: gmane.emacs.devel Subject: Re: Network security manager Date: Wed, 19 Nov 2014 06:43:39 +0100 Message-ID: <8761eb68z8.fsf@alrua-karlstad.karlstad.toke.dk> References: <85a93pj1n5.fsf@stephe-leake.org> <87sihg7r73.fsf@alrua-karlstad.karlstad.toke.dk> <87a93oilxl.fsf@lifelogs.com> <8761ebg6b5.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416375846 18363 80.91.229.3 (19 Nov 2014 05:44:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Nov 2014 05:44:06 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 19 06:44:01 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xqy3d-000797-5f for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 06:44:01 +0100 Original-Received: from localhost ([::1]:56579 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqy3c-000354-HA for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 00:44:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49563) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqy3U-00034y-Vw for emacs-devel@gnu.org; Wed, 19 Nov 2014 00:43:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xqy3Q-0006am-NL for emacs-devel@gnu.org; Wed, 19 Nov 2014 00:43:52 -0500 Original-Received: from mail2.tohojo.dk ([77.235.48.147]:51611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqy3Q-0006ai-EY for emacs-devel@gnu.org; Wed, 19 Nov 2014 00:43:48 -0500 X-Virus-Scanned: amavisd-new at mail2.tohojo.dk Original-Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id B9DD21E6339; Wed, 19 Nov 2014 06:43:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1416375444; bh=0L3GJrFtHWjWI5j3J0CSFVrfPpE6g5tNQJ5MqNeps30=; h=From:To:Subject:References:Date:In-Reply-To; b=tJxP/pYT1R5jDmD+N51hZO/bp2L1HN9pNA8Sb7CL2OMedWvFQjFC64gxRq2zx2FGF pWlHtmdPqzWIUYLIyGhbgl1oH7Lf+dIMXGFAuhkOQol6xeDERMVEQesdRarJe/lA7B y1tovinBSSUtt8HSeJdIiH8UnM5QGtLDNsUwWW2A= In-Reply-To: <8761ebg6b5.fsf@lifelogs.com> (Ted Zlatanov's message of "Tue, 18 Nov 2014 23:31:10 -0500") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.235.48.147 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177713 Archived-At: Ted Zlatanov writes: > * uses SSH-style gnutls_store_pubkey() and gnutls_verify_stored_pubkey() > to DTRT and pins the public key rather than the certificate > fingerprint. The pub keys are stored by default in a way that lets the > user look them up by hostname, but we can customize that. And it's > mostly handled by GnuTLS internals as far as pubkey extraction and > verification. AFAICT this is functionally equivalent to what is currently in NSM; except it stores the public key rather than the fingerprint. I am not sure if there area any security implications to storing just the fingerprint... > * does DANE auth (although I don't know the details on DANE, the > client implementation looks reasonable and Toke suggested it) I think the right thing to do would probably be to check DANE and use that as an additional input to the NSM dialog. I'd suggest the following: - Supply the DANE status as part of the 'certificate information' blurb when popping up a prompt. For many (most?) setups this will be 'unknown' either because no DANE info is published in DNS or DNSSEC validation fails (or both). - If valid DANE info is available *and* this doesn't match the shown certificate, treat it as a reason to consider the certificate insecure. I.e. treat a positive DANE verification as information to present to the user, and a verified failure as a cause for alarm. This corresponds to the current DANE RFC recommendations AFAICT... > * checks OCSP for revocations using cert_verify_ocsp() in the same > cli.c This would probably be a good idea to implement in any case. -Toke