From owner-svn-src-head@freebsd.org Wed Jun 20 16:10:53 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 163671021C3A; Wed, 20 Jun 2018 16:10:53 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f66.google.com (mail-it0-f66.google.com [209.85.214.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A447B82714; Wed, 20 Jun 2018 16:10:52 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f66.google.com with SMTP id y127-v6so372474itd.1; Wed, 20 Jun 2018 09:10:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=zuDBVgnUAhriBR0dqjkuHLcl6Ty3pd1p3Als1CSbdmk=; b=cV7vg2VLIVuQ6Zn52V5kfuKNTCEb9wpdtXdPdbqIR0+L9fYk2z2sDB2EwlRTHmcheM 8xOTLd2GT0/KhaCSyzCy2t27ZT3Yb8B3uCHkSFHNO5Aop0zh8kxDDkbTOA8KYLcnnN9K A4b2RX35RTOgLnH4gPg6tgnY+WnomO1lDFVOQN6FOibKzwIswNyl8swkH8ekUCMTH8BM WWiBvvU/CvPtWZwe7sm625oF6VWSD8rHbiDI3/PTOMdpPUKxd3U8t+mHcGpXUp5ekThC ymvQZVIiZ7yculWBHc8bhp7PDDUbGsm34PDeXturdDyL/+AIRrrfdDl9QaZQyFGmJr2S UtTA== X-Gm-Message-State: APt69E1Q9FQCTSAgrmCjgk4oVHwCrJglikKjmN1+F+x25WQiBo/WqAt6 FPTEdulJHCNAZ7PfJSPudYJ83Gap X-Google-Smtp-Source: ADUXVKK1jswHEQhaFbNZYRSzStYFSpP1rMydpicF2l6p6QdBGYpgaMXaBDwGOAlt4TZz3n6ZbHf0Jg== X-Received: by 2002:a24:690f:: with SMTP id e15-v6mr1990711itc.70.1529509410458; Wed, 20 Jun 2018 08:43:30 -0700 (PDT) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com. [209.85.214.50]) by smtp.gmail.com with ESMTPSA id n204-v6sm1230582itg.7.2018.06.20.08.43.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 08:43:30 -0700 (PDT) Received: by mail-it0-f50.google.com with SMTP id y127-v6so304733itd.1; Wed, 20 Jun 2018 08:43:30 -0700 (PDT) X-Received: by 2002:a24:ed4a:: with SMTP id r71-v6mr1999052ith.53.1529509409886; Wed, 20 Jun 2018 08:43:29 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:5995:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 08:43:29 -0700 (PDT) In-Reply-To: <96021.1529475664@kaos.jnpr.net> References: <201806200108.w5K18sIR050132@repo.freebsd.org> <96021.1529475664@kaos.jnpr.net> From: Conrad Meyer Date: Wed, 20 Jun 2018 08:43:29 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r335402 - head/sbin/veriexecctl To: "Simon J. Gerraty" Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 16:10:53 -0000 I want to preface this by saying: this discussion should be happening in either arch@ or phabricator, after the patch series was temporarily reverted pending necessary improvements. I have asked for the series to be reverted and am still waiting on that. I am happy to promise to respond promptly to updates on this particular series so you are not waiting for two years again. I think it's quite close to something reasonably general, but as-is, it is worse than useless =E2=80=94 it promises a security feature but _does not deliver it_, which is the "emperor's new clothes" of security. On Tue, Jun 19, 2018 at 11:21 PM, Simon J. Gerraty wrote: > Conrad Meyer wrote: >> First and foremost: nothing is actually signed, anywhere. The > > The signing of manifests is external. The veriexecctl tool is I assume > a straight copy of what's in NetBSD (I've not looked at it in at least a > decade). The signing of manifests does not exist in the patch series committed. (If NetBSD does something broken, that is not an excuse to copy it.) > A veriexec loader that leverages signed manifests requires some signing > infra. That's a big topic all by itself. It *may* require that. However, even without that, admins could reasonably manage their own PKI in some fashion, independent of FreeBSD's infra. But it requires the support code to verify signatures, as in the "verify" part of veriexec, which is wholly absent. > As I mentioned in my talk at BSDCan, (FWIW, I was not at your talk, and it is not a justification for bad design or implementation anyway.) > the signing server we use is open > source and handles pretty much anything OpenSSL can, as well as OpenPGP > (and others). It doesn't really matter if there's a signing server, because nothing in the patch series *verifies* signatures. > Tweaking the veriexec loader to only process manifests after > verification is not hard Then I even more do not understand why it was not done prior to commit. > - one of the first things I did when pulling > veriexec into Junos almost 15 years ago. > >> As a corollary to the above, the name "signature file" is used >> repeatedly in the code, which is misleading. The file contains hashes >> (digests), not signatures (MACs). The file itself is unsigned. >> Nothing about this has signatures. > > NetBSD refers to the hashes as fingerprints - AFAIK that terminology is > retained. Fingerprints is fine, "signatures" is not. "Signatures file" is used to refer to the manifest file, which only contains fingerprints, in multiple locations in the code. > If the term signature is used to refer to anything other than the signed > manifests that should be fixed. Should have been fixed prior to commit, yes. >> There's absolutely no reason to use sha1 or ripemd in new designs. >> These should be removed. > > Sorry I disagree - not with ripem (we never supported that or any of the > non-NIST approved hashes), but sha1 is still approved by NIST for > firmware integrity checks - which is what this is, and sha1 is cheaper > than sha256. Again =E2=80=94 this is a discussion for arch or phabricator, with the seri= es reverted first. I reckon you're wrong. If you're unwilling to trust me, I believe you should get and accept input from a 3rd party vaguely familiar with cryptography (maybe cperciva@ or gordon@ or delphij@) before introducing SHA1 or Ripe-MD in a novel integrity-protection design. (Some modern Intel and AMD CPUs have intrinsics support for SHA-2, and on those machines SHA-2 256 is about the same performance as SHA-1.) Performance is absolutely not a reason to use a known weak hash algorithm in 2018, especially when the feature as-committed has so many other glaring performance problems. If you care about MAC performance in a secure algorithm in 2018, perhaps look at any of these great options: * SHA-3 (Keccak) * Blake2-b * Poly1305-{AES,Salsa,ChaCha} All have highly efficient software implementations that smoke SHA-2 and don't have SHA-1's known weakness. Blake2 is even in-tree already. > As I mentioned in my talk we've included support for sha256 for 10+ > years, FreeBSD has had this code for 0 years. It's a novel feature here. There is no reason to introduce SHA-1 in novel security features in 2018. > but do not plan to drop sha1 until NIST deprecate it for that > purpose since boot time is a very sensitive subject for us. See above. There are lots of secure hashes faster than SHA-1 without its known weaknesses. >> The patchset is littered with style issues. One fairly obvious issue >> is mixed indentation styles =E2=80=94 some files vary between space and = tab >> indentation from line to line. > > You can probably blame me for some of that. > I only recently found a style9.el that does a half decent job of > formatting per style(9). To commit to the tree, you are supposed to be able to get it right, or at least close to right. >> Please revert this patchset. It's not ready. >> - Maybe use HMACs instead of raw hashes > > Why? Again, this design discussion is for arch or phab. HMAC have a number of advantages over raw SHA-1/-2: * Key verification * No length extension attacks Neither of these may apply here IFF the manifest is signed and trusted, and there aren't other implementation flaws. But as-committed, there is no signed manifest. A MAC implementation would enable just storing these values as extended attributes on-disk instead of a separate file that gets loaded. Another design question for arch. >> - Maybe sign the source-of-trust file > > We do. As noted above, we cannot upstream that until FreeBSD has > suitable signing infra. I disagree. What was committed absolutely does not sign nor verify the source-of-trust file. And no, upstreaming the signature verification code is completely orthogonal to implementing signing infrastructure. The "veriexec" patchset in FreeBSD today: 1. Does not verify anything in a cryptographically sound manner 2. Slows down all concurrent access to associated filesystems Why is this either necessary or helpful to be in the FreeBSD tree as-is? I don't think it is, and you should revert it. Please. I don't know if there's a maintainer timeout on this kind of thing, but, you are forewarned. Thank you, Conrad