From owner-freebsd-security@freebsd.org Sun Oct 22 22:14:45 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C3FBE37B81; Sun, 22 Oct 2017 22:14:45 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 7967E770EB; Sun, 22 Oct 2017 22:14:45 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id CD4FE2D07; Sun, 22 Oct 2017 22:14:40 +0000 (UTC) To: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org From: Eric McCorkle Subject: Trust system write-up Message-ID: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> Date: Sun, 22 Oct 2017 18:14:40 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 22:14:45 -0000 Hello everyone, The following is a write-up of my current design for a public-key trust system: https://www.metricspace.net/files/freebsd_trust.pdf Some of you are certainly familiar with some or all of this; I've discussed parts of it before on -hackers and -security, and I discussed it in greater detail in BoF sessions at vBSDCon. It seems things are heating up in this direction, so I'd like to get this out there and get discussion and feedback. I plan on undertaking work on this in the very near future, especially since the commit-train for GELI EFI is ready to arrive in HEAD. A bit about the format: this is sort of the "meat" of what I hope will be a paper some day, but it's still an initial draft. Moreover, it talks about things I'm planning as if they exist, mainly because I don't want to have to go back and rewrite everything in the future. In reality, most of what I talk about is just a proposal at this point, with a few bits being implemented as a PoC here and there. Please read and consider the designs I've proposed. I welcome any feedback and suggestions. I'll give it a week minimum from today before I resume any work on this stuff. Note: Apologies for the external link; I had originally included this as an attachment, but it was too large. From owner-freebsd-security@freebsd.org Sun Oct 22 22:31:42 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86A09E38340 for ; Sun, 22 Oct 2017 22:31:42 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 4425A779FC for ; Sun, 22 Oct 2017 22:31:42 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x231.google.com with SMTP id 31so24079511qtz.9 for ; Sun, 22 Oct 2017 15:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=bSyhe9uYPpe7TOlfCzaPDkrNgbYDdmbbs/LdFqmQ8Sk=; b=e4hbPJ7fOT9GE8X35njVH+ahYhtbSVCkhIY6nkC03CXws/BCRJ0T+RD7nMBS5RIzfo yUBzc39yerQu5Ym95YRwcku9uBRYcv1FN5/j34xxnNmsRvGq3oqvnotANbabplzNdVot jpNH5yojNwwpT7YLAfNP42rJqekWPB0AZ3j6bLLs2Lr2t0Gsqr9SoX2oMyOWwueLh11U JwrGW/Pji8namtmd45JT3j6O8OSwO1tv7IbxPXfltPKXI9nM5PENPZKQCrO/YSNFP7et os1LAIvQ1P+Bv2iscfMRf6LY9FClCRYzY9GDMGMrUEUffauMXbT2jgWAdlh21tvQR4qx Ggcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=bSyhe9uYPpe7TOlfCzaPDkrNgbYDdmbbs/LdFqmQ8Sk=; b=oZAUT3jtaHI8OXlz1JiC2eGXQw8iKoJbUTHPtvNoXSeVwdm+IYa3r406MXsANRpYno SpF9QdpUWB4brjfBZ4Op3gglTTakxJ4cFNh5erLmfyXNUOPrua5v2dfX9GcV3mpu8y/A s+XvvWDMsByUc3tw7kbzuctD1BLR3r2iyV+8gp95fOk8m/epREjumBvcX1uQiwenINaR pfrmf3ETh5WU6nmZ/xRv7S4wE6X0q6Wmze3535aQWUIQC+OtmQzQBRwc+qINCGZwag/1 wyWgtBALXetkWnqUR4C+AHhn1F5+iC1Y1Egj4v8sULIc7xlMduzX5KegW+2DBh4+6cjI Vycg== X-Gm-Message-State: AMCzsaWmDWtylWunPmH+Kxf6Oyo+wCmx0IaHBj9CHzqx6eg2+Gqjfo/T SP6seoh3HioU9OMOtkCk2xhePOMO2Fg= X-Google-Smtp-Source: ABhQp+RxR23Uchv3/7x9v7yj6V5tlmfgNjACTmSN6H/nMM6RJbSZb/DKulUrNfLsO5q+gQVJTJTdPw== X-Received: by 10.237.42.230 with SMTP id t93mr17709929qtd.317.1508711501122; Sun, 22 Oct 2017 15:31:41 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-230-154.bltmmd.fios.verizon.net. [100.16.230.154]) by smtp.gmail.com with ESMTPSA id k79sm3809705qke.28.2017.10.22.15.31.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 22 Oct 2017 15:31:40 -0700 (PDT) Date: Sun, 22 Oct 2017 18:31:33 -0400 From: Shawn Webb To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Trust system write-up Message-ID: <20171022223133.nkcpkhtl7s7kzgs5@mutt-hbsd> References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zanh2tn2izgbdqkn" Content-Disposition: inline In-Reply-To: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170912 (1.9.0) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 22:31:42 -0000 --zanh2tn2izgbdqkn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 22, 2017 at 10:14:40PM +0000, Eric McCorkle wrote: > Hello everyone, >=20 > The following is a write-up of my current design for a public-key trust > system: >=20 > https://www.metricspace.net/files/freebsd_trust.pdf >=20 > Some of you are certainly familiar with some or all of this; > I've discussed parts of it before on -hackers and -security, and I > discussed it in greater detail in BoF sessions at vBSDCon. It seems > things are heating up in this direction, so I'd like to get this out > there and get discussion and feedback. >=20 > I plan on undertaking work on this in the very near future, especially > since the commit-train for GELI EFI is ready to arrive in HEAD. >=20 > A bit about the format: this is sort of the "meat" of what I hope will > be a paper some day, but it's still an initial draft. Moreover, it > talks about things I'm planning as if they exist, mainly because I don't > want to have to go back and rewrite everything in the future. In > reality, most of what I talk about is just a proposal at this point, > with a few bits being implemented as a PoC here and there. >=20 > Please read and consider the designs I've proposed. I welcome any > feedback and suggestions. I'll give it a week minimum from today before > I resume any work on this stuff. Hey Eric, Thank you so much for working on this. I do have a few questions. I'm curious about the rational behind not requiring expiration of trusted root key material. Can jails contain a different trust chain than the host? Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --zanh2tn2izgbdqkn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlntHEIACgkQaoRlj1JF bu585g//SLA5OM7zRX/0SziOYf5ref5HARdM9T0BjmEejcLGA9ZgcwH3i0krPJXY IznjVMVlIpXcqUA5CYrNjSaaxs1h2TIS/wxVrhPrtpM8NOezZNxOT0fm8IaG624h V1E0YO+TYn2Iy3yBrzAJI+kFnJ998cvTauapAWxtvpo3AJUfDI/Lx02yEbq21U+J JJV5vvYE029on0irPWepCJdRz9hiwUCI/f9t3yXlJLae01RgJObwpU+SXgtGOx43 e/HO/za/EEgDmB7njSUyw0sw4QWm7F1VXhemClP9jq7C+yedIkExJFfE6VynRDta crR9StOctmkdnf4M/48NGmGUndRBLDrwf0b6+gmSuZTrzP4WOkYMK5bJYJPA2xx5 DbRCOpqIc+Jvr+Qfnr2mXnUKmjM+WWo/FCx/pc7eFMaNyFQpSBpBptO/syuOTvJU MAmCBdreT56Tz1uce7JH6Q3sOQ3C3HLFn4kB1F5l4kTskiZSMOykFEUmgEfz75kF gnXCT/dJVfsYQCbGeQlU2+wCK1tt03p+4pcSyCK7cMdSd7RCjrt7H2G44UGet+lH fH3Q0FuCxfD8TuLaG5az8NpdrAB24cPPM8wghyunqDllNqb19731d6fK4+EJBmbF OOniNXf0EA3CalTN1dtRluABHZyxWidZKudUot77xJ1jqlPLDKM= =vbis -----END PGP SIGNATURE----- --zanh2tn2izgbdqkn-- From owner-freebsd-security@freebsd.org Sun Oct 22 23:21:11 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 010C3E3979C; Sun, 22 Oct 2017 23:21:11 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id CE34D7D9D7; Sun, 22 Oct 2017 23:21:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 9DA2D2D2D; Sun, 22 Oct 2017 23:21:09 +0000 (UTC) Subject: Re: Trust system write-up To: Shawn Webb Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171022223133.nkcpkhtl7s7kzgs5@mutt-hbsd> From: Eric McCorkle Message-ID: <96ff2a56-5089-eb4e-cf57-6c6d2cb4667e@metricspace.net> Date: Sun, 22 Oct 2017 19:21:09 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171022223133.nkcpkhtl7s7kzgs5@mutt-hbsd> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 23:21:11 -0000 Accidentally replied to -arch only, re-replying to all lists On 10/22/2017 18:31, Shawn Webb wrote: > I'm curious about the rational behind not requiring expiration of > trusted root key material. > So, I'd say consider most of this written in pencil at this point (minus the signed ELF extension; I think that's a particularly good point in design space). My thinking on root keys is that there really ought to only be one for a given system, but I'm not so convinced of that that I'd bake it into the spec. Certainly, though, you need at least one good root key to stay operational. If you have expiring root keys, you get into all sorts of nasty cases where your last root key expires, forcing the system down, or a system can't be booted because its root keys all expired. And expiring root keys + can't add more root keys means every system effectively has a countdown to running out of root keys. I didn't mention it, but I could see provisions for adding/revoking root keys that hook into some sort of deeper hardware mechanism, say TPMs. I think that's out-of-scope for now, but it's worth thinking about. Perhaps expiring root keys could be added along with a mechanism like this. > Can jails contain a different trust chain than the host? I hadn't really folded jails into this yet, but I'd say that's a definite requirement. It kind of kills the whole virtualization capability of jails if you can't do that. I'd say you'd probably want jails to have the option to inherit their parent's trust DB, as well as establish their own root keys. From owner-freebsd-security@freebsd.org Mon Oct 23 07:11:27 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDA9CE42CB3; Mon, 23 Oct 2017 07:11:27 +0000 (UTC) (envelope-from romain@blogreen.org) Received: from marvin.blogreen.org (blogreen.org [151.127.25.53]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5F864CBC; Mon, 23 Oct 2017 07:11:26 +0000 (UTC) (envelope-from romain@blogreen.org) Received: by marvin.blogreen.org (Postfix, from userid 1001) id 7A2A2A6DAD; Mon, 23 Oct 2017 09:11:20 +0200 (CEST) Date: Mon, 23 Oct 2017 09:11:20 +0200 From: Romain =?iso-8859-1?Q?Tarti=E8re?= To: freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org Subject: Re: Trust system write-up Message-ID: <20171023071120.GA72383@blogreen.org> Mail-Followup-To: freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> X-PGP-Key: http://romain.blogreen.org/pubkey.asc User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 07:11:27 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Eric, On Sun, Oct 22, 2017 at 06:14:40PM -0400, Eric McCorkle wrote: > The following is a write-up of my current design for a public-key trust > system: >=20 > https://www.metricspace.net/files/freebsd_trust.pdf Two minor things while reading: 1. p2: from a end-user perspective, `trustctl` expects DER encoded certificates and CRL; while `certs` and `rootcerts` outputs PEM encoded certificates=E2=80=A6 So the formats are not the same, and may= be consistency would be advisable here; 2. p3: 'the preferred configuration' is said to be the most used one, but as described it only includes a single crt+key and does not look suitable for distributing upgrades with freebsd-update(8). Unless I missed something, I guess it's just the way it is described that needs disambiguation: - "local nodes" are basically what is described as "Preferred configuration", and have a single key+crt. So these nodes can only run the code they signed. - "high-security institutions" are kept as it, that is a single crt; So these nodes can only run code signed by the institution. Hybrid systems can be built by having more than one root node: - "preferred configuration" have a local key+crt (as an local node) AND the FreeBSD's project crt. So these nodes can run FreeBSD's code and their own code. - "standard FreeBSD images" as described have the FreeBSD's project crt. When installing, they generates a local key+crt and add them with the FreeBSD crt to the new system's trust store. So these images have the "high-security institutions" scheme, and install systems in the "preferred configuration" scheme. Thanks! Romain --=20 Romain Tarti=C3=A8re http://people.FreeBSD.org/~romai= n/ pgp: 8234 9A78 E7C0 B807 0B59 80FF BA4D 1D95 5112 336F (ID: 0x5112336F) (plain text =3Dnon-HTML=3D PGP/GPG encrypted/signed e-mail much appreciated) --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEgjSaeOfAuAcLWYD/uk0dlVESM28FAlntlhUACgkQuk0dlVES M28IUAwAkC1TcnDuhF67t+1RbvZL5oTxtDBQjzzOTiIhX+W/Q8oZDMPGa2xpAyPP BxPX8oCbLLsWCP/FkVmMzxHz0zNSFTMQSPCzLfkhPUZzVNlG6XcF211U97umofQf ij2pvazZXLYcaH6sFkVbpjIGqoLehCgCnU87imD/stB8v1bpmr8qTOrNG0qVH5BF pWFa1rnRCouY6YRvyNxwmzW/tNbEeFqJ07t8vDSjG48bF7jbSezM/SLzmettl9Fi EFGs1GTLtqAVLX3XomajDGd+N76xAq6WEL+g5ys2Rm31BJoj3JcfREoHzEzSGiEW LaTJllt2r5Bz3EMPKGqf6i/fd8YiyJfSn/FUrpdO4iWHnYPEqBCVQ74ran/l3trX OYlFTyjwbG0/ocTxO1ZQ3wmdQ06dor41PiL6Rylis2ZZNxXI0IzjjK667Bs0LxHm +cBsCGDnmgcAhRPy7pgeXpfEd/w3VZY3mIB3kGYpYXQ8a5aJiqv7Pq5JEt/xndqM rPX0N+/z =ihHe -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-security@freebsd.org Mon Oct 23 16:14:59 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61A3DE4F227 for ; Mon, 23 Oct 2017 16:14:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F1C2F75C7D for ; Mon, 23 Oct 2017 16:14:58 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 4b3e415d-b80d-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 4b3e415d-b80d-11e7-a893-25625093991c; Mon, 23 Oct 2017 16:14:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9NGEjrb001381; Mon, 23 Oct 2017 10:14:45 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508775285.34364.2.camel@freebsd.org> Subject: Re: Trust system write-up From: Ian Lepore To: Eric McCorkle , "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org Date: Mon, 23 Oct 2017 10:14:45 -0600 In-Reply-To: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 23 Oct 2017 17:48:44 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:14:59 -0000 On Sun, 2017-10-22 at 18:14 -0400, Eric McCorkle wrote: > Hello everyone, > > The following is a write-up of my current design for a public-key trust > system: > > https://www.metricspace.net/files/freebsd_trust.pdf > > Some of you are certainly familiar with some or all of this; > I've discussed parts of it before on -hackers and -security, and I > discussed it in greater detail in BoF sessions at vBSDCon.  It seems > things are heating up in this direction, so I'd like to get this out > there and get discussion and feedback. > > I plan on undertaking work on this in the very near future, especially > since the commit-train for GELI EFI is ready to arrive in HEAD. > > A bit about the format: this is sort of the "meat" of what I hope will > be a paper some day, but it's still an initial draft.  Moreover, it > talks about things I'm planning as if they exist, mainly because I don't > want to have to go back and rewrite everything in the future.  In > reality, most of what I talk about is just a proposal at this point, > with a few bits being implemented as a PoC here and there. > > Please read and consider the designs I've proposed.  I welcome any > feedback and suggestions.  I'll give it a week minimum from today before > I resume any work on this stuff. > > > Note: Apologies for the external link; I had originally included this as > an attachment, but it was too large. > _______________________________________________ Any thoughts on how to validate executables which are not elf binaries, such as shell scripts, python programs, etc? -- Ian From owner-freebsd-security@freebsd.org Mon Oct 23 22:28:03 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82F3DE56925; Mon, 23 Oct 2017 22:28:03 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 520192A40; Mon, 23 Oct 2017 22:28:03 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id B28ED2F80; Mon, 23 Oct 2017 22:28:02 +0000 (UTC) Subject: Re: Trust system write-up To: Ian Lepore , "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <1508775285.34364.2.camel@freebsd.org> From: Eric McCorkle Message-ID: Date: Mon, 23 Oct 2017 18:28:02 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1508775285.34364.2.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 22:28:03 -0000 On 10/23/2017 12:14, Ian Lepore wrote: > Any thoughts on how to validate executables which are not elf binaries, > such as shell scripts, python programs, etc? I hadn't really thought in depth about it, as my main initial goal is signed kernel/modules, but I have given it some thought... Arguably the "right" way to do it would be to have the signing mechanism be part of the platform. For example, the JVM has conventions for jar signing. Not clear how this relates to shell scripts though. An alternative is something like the NetBSD veriexec framework, where there's MACs for specific files. That stuff is mostly orthogonal to the public-key approach I'm working on here, but there's possibly some interplay. From owner-freebsd-security@freebsd.org Tue Oct 24 00:00:55 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88E19E2BA92; Tue, 24 Oct 2017 00:00:55 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 5F6CE652C5; Tue, 24 Oct 2017 00:00:55 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 13E7B2FC6; Tue, 24 Oct 2017 00:00:54 +0000 (UTC) Subject: Re: Trust system write-up To: "Simon J. Gerraty" Cc: Ian Lepore , "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <1508775285.34364.2.camel@freebsd.org> <72903.1508799185@kaos.jnpr.net> From: Eric McCorkle Message-ID: Date: Mon, 23 Oct 2017 20:00:53 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <72903.1508799185@kaos.jnpr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 00:00:55 -0000 On 10/23/2017 18:53, Simon J. Gerraty wrote: > Eric McCorkle wrote: >>> Any thoughts on how to validate executables which are not elf binaries, >>> such as shell scripts, python programs, etc? >> >> I hadn't really thought in depth about it, as my main initial goal is >> signed kernel/modules, but I have given it some thought... >> > >> An alternative is something like the NetBSD veriexec framework, where > > Yes, as previously mentioned the verified exec model deals with this > neatly, and btw is more efficient than signing individual files - as is > needed with ELF signing etc. I think for linux based platforms using IMA we > need to generate 20-30k+ signatures, vs about a dozen for platforms using > verified exec, verification is also more expensive I'm told. Hmmm. There's advantages both ways, and I'll probably end up supporting both, as it's useful to have an in-band mechanism as well (also, I've already implemented signed ELFs). However, there is a definite advantage to having one signature for a huge number of MACs. Moreover, as I mention in the paper, the most feasible quantum-safe signature scheme at the present is SPHINCS, which has signatures about 40Kib in size. That's pretty terrible if you're signing each executable, but if you're signing 20-30k MACs at 16-32 bytes per code plus a path, suddenly a 40Kib signature doesn't look so bad anymore. It would be pretty great to roll out a trust infrastructure AND viable quantum-safe signatures. I could also see a combined scheme, say, where ELF files carry a UUID which indexes into a MAC manifest. From owner-freebsd-security@freebsd.org Mon Oct 23 22:53:10 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C03BE5735F; Mon, 23 Oct 2017 22:53:10 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0134.outbound.protection.outlook.com [104.47.33.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3FFF3BF3; Mon, 23 Oct 2017 22:53:08 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gL7yP/zlyheW2y6AMkUzAYLenl6Y/1mSP8BNcXkHekU=; b=g+txXp8dUJNVcuXgqnIVZRS+qnMG0U6q70skpVRHgModiRdorjGO8AeaLfq63AafcOaCKc7OpqaEtOWE1ACkNwZSUh63ZPjhCYHjtPa9gBmNY5RkNFlrwJDymi65snE4WM87bPJOlXjAqExGc5Mi/jQvHfaFzIYgpvgqi8QPBjw= Received: from BY1PR0501CA0003.namprd05.prod.outlook.com (10.162.139.13) by BN6PR05MB3012.namprd05.prod.outlook.com (10.173.19.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Mon, 23 Oct 2017 22:53:06 +0000 Received: from BY2NAM05FT037.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::201) by BY1PR0501CA0003.outlook.office365.com (2a01:111:e400:4821::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.178.2 via Frontend Transport; Mon, 23 Oct 2017 22:53:06 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT037.mail.protection.outlook.com (10.152.100.174) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.156.4 via Frontend Transport; Mon, 23 Oct 2017 22:53:05 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 23 Oct 2017 15:53:05 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v9NMr4LT015550; Mon, 23 Oct 2017 15:53:04 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 29CAE385567; Mon, 23 Oct 2017 15:53:05 -0700 (PDT) To: Eric McCorkle CC: Ian Lepore , "freebsd-hackers@freebsd.org" , , , Subject: Re: Trust system write-up In-Reply-To: References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <1508775285.34364.2.camel@freebsd.org> Comments: In-reply-to: Eric McCorkle message dated "Mon, 23 Oct 2017 18:28:02 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72902.1508799185.1@kaos.jnpr.net> Date: Mon, 23 Oct 2017 15:53:05 -0700 Message-ID: <72903.1508799185@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(2980300002)(24454002)(199003)(189002)(50986999)(76176999)(4326008)(105596002)(46406003)(97876018)(7696004)(6916009)(69596002)(2950100002)(2810700001)(50466002)(305945005)(81166006)(23726003)(68736007)(81156014)(47776003)(106466001)(8676002)(50226002)(356003)(478600001)(53416004)(76506005)(2906002)(8936002)(5660300001)(229853002)(107886003)(86362001)(189998001)(97736004)(117636001)(54906003)(7126002)(316002)(9686003)(55016002)(16586007)(6246003)(53936002)(6266002)(97756001)(77096006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB3012; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT037; 1:5lJiF6R0vHAsKDfuqb2+3kH0xb8WP8vB4mkUgyffEu2FZ2sejv5TP+BQoLP+sbYTD3d0kfvtZTEYhh8aYmuP/s2SxWdzikUa9w6XjpXyhPH89pMlNrzz6g01HZbMwq1b X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ea03b818-4e0d-41cb-a096-08d51a68d2a9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:BN6PR05MB3012; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3012; 3:dMgwDwonGgbA4DypvWJOlt/WLcRJp93C1OhdCdwlHaaQbbVe+1/oHLkS8SipU3WRn0jBEEXf36SXKxtQKEBz65SW42KufjTTLmNyQMdm6RW4zJIey3FRxmGOjln+NpL8G7WEwvLeVXhRK4NjV4brlz6XuCOu0skftdK1SZGLSzGT+hQ9omQFqGiNCnrKkGxmSfAbOdj6uox+Qy/A8DytZYq5A/uA1K9vrVXwmKvZmlZLFu5fOLID39Zmw7cyOvd1oMKkWPYMzlAMWnrh9m2sNpwH6qTpc24sTOHbn8dBuztsm40WL+0hRlTYI/2KMsgBg8L5o1FKZPXT/Qk30sRJM6Ezlg3bFGogj7EApyy3fPQ=; 25:9kBWzNzt4Dvpf5/1sJkDwBBC2zx+TYXtOb2HY0QMiVj0gtkQqTLc8L1W6NDBjRrGnOb3TkYb1QWgeotEV4zX6k09d0uJ7/5xhNUhQj/6jWFimP2MbvpIpCn9HrdRofYg41/GfvuhuTlcOZ4wDAkJC0gq+pdqtTBM98UCGVoJbME4LyLDfE1t54Jm4Z9PpaJokleAIgcdS/T1pQr4VZ4v8Vo1XGcfUpsap6ucjajRRwLpxkqGX8WvurF6Fygyw4fCNSJpRFD46GwLMFaSFg3YRQ1D/EByEM/PljrK0DNThWWeKHdVZKY4hCNGOWRfff02eA/OzUNlZLBQUU8EE56m4J3HWZwUwQKV2ptHGUYgWFc= X-MS-TrafficTypeDiagnostic: BN6PR05MB3012: X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3012; 31:27pbbRLJkKVTUAU8eICFT1zeQS5Q/EJYrfAcGHX7Z7jsml6qlVnDmEVYGhoz/dgF9WhE6tSAIM5170RP8KDJJ3dhLXY6iOs8G789IdjEDefbB23RUvSUu0xokuLQpToR6gN8PANmp4QccmTd3XzkAn2yfacQVSWQHt95OnGgbWr973pu8EIM6ep0sTCgBNXR9k21tLhaLl1+PWsuaviPNA+o2NCDXQBMLnLY+l4c7lc=; 20:1VMgI5TTgxM0pmryAlMQQiQsjmyDE4/6YqoAGkS3q3pYUlaRXgk57MSM3npci28N8h6oVKINA06wSmJUyUvDoT8mF87Zn+mL/wkIgeG8yRYT+TkCqZWOLeaHSQe0ymUCN1GgIa0SPbEnS8M9F2gGKRgeuiZkr8GJz3tJHmYo0pprGNnPnxvMWwWb7R11QC3pDUdrxJu+4+Xe8W2bW4ov9t0K7TA3kVRBSwtetPgGK7p54weykkgHGy0k+PJpRRnRsR/wStbCF4Xe9fWBjwqqKQ9Xh+qdrkfYDxnKEIpDo6b4kxLAJFlwBicpTLbFW+cGnWuvkm35pRTTxdC1zTFrryG0/b3rDRGGJ222snpBwbWemHAOo7uWBt/dWuyMkh6V1XNUm6P0XH5jPqsDu+zLQSye8tUaEfapRRYYIpIXzTJ50wa7UDNYU56VYo6FIXxbPL/7pJFm3tZn+rSp0ST/MJdckGtjuJAA7c3iRPIQ7F5hK2Le/vm8/A2DHwOAftON X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231020)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93003095)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR05MB3012; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR05MB3012; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3012; 4:4Bd8ehGZAtnIbEXO+/Dcn/9fU1qJyT1ALvlMakdQW0BfmtFx/Q6IMpYWvONMihbrdSz3LwAfKV/ji8hUlZ80aDWbXo9O9W42PD27sYYz5VkdqjZJvH/cVk4B9hZQeCKHW6EKddLicLc+9NPVV0c+zTHlJHI/AY7DCm5ILC5KqSiBBcNChRs0ZYdWxE1Zl6g0s6GnGu2OHtMupdEUHJzvzBbUXbSG3dTVMeVhRyT21yM4+95TtM0q6D4YS9cU9b+I X-Forefront-PRVS: 046985391D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR05MB3012; 23:2kUZ3nPRndR2j3HQUmgN+XSe7N80N5pxeMwIEwfQO?= =?us-ascii?Q?K1lkehWoyQfZ5JPi741lT5MKpUv9iNSL65j5KQyW6XOVJWS2HONwfcfIqfSE?= =?us-ascii?Q?X3rP+AWhDLjUNoD9Iy1q41+wXnMjt+WVVbBmIiMa9Pegej9c0Up6uW+SkwW/?= =?us-ascii?Q?xy3g+ZeFYewr9SIubJRjBObGfz18JBAq65w17bMGWqDKgWGIOONIMUlICP6S?= =?us-ascii?Q?nHzB6suYMHerPDnLp6SO0bJrzdbzBcMPUDdYkPEnpDJC1Xvon5qON+eLLg4b?= =?us-ascii?Q?teZfEMdqGDIZ8u+dz1t1ehwhzhE5mH34GJk5VLPblVEqmUgAcSAytAXAElwZ?= =?us-ascii?Q?FgrsX/NpsHlzNsiApouwBpr2X0HBQqjzVIvoNYxsjVIBmsl1oDFDSXT4PO1j?= =?us-ascii?Q?Pkw4x8oOrEH9ynwtmZGIwxfN28sK0v84FIbWiUjJaDKTHq/PbJkjQ+gvPwXA?= =?us-ascii?Q?88Gcq/CaqdZ5OgATksOv/8M0M1mdSnzlwO8mr7vlYc3QqEkNvp5ui/sRX6ZY?= =?us-ascii?Q?LPFJvpRwxEOLvPvPlzLE6MU/Jr3lzt83UcKiskck+rkAx/6NQZ1+GKR99cLO?= =?us-ascii?Q?44TsClPe5hJhbt0ixz7O26quxv6tuiy828LGHAMBWj2IYzejCtHcNi4OErad?= =?us-ascii?Q?fwLSCnbesmylClBOl1oC1y0mnMSNXN2hj3tlEiDOs8IQjYyh9wwDbHCHC92+?= =?us-ascii?Q?t6M2AENHyyrudF/pt5KvepDWUItoXqWmxFbolh9NPyoeJa6u4fBqIE3y/i4q?= =?us-ascii?Q?mk/RPKzGdgzDMyVMGdxoayCR/zvLcua7IiDy69S0i5SVsQlFkb9E/TBmnjqQ?= =?us-ascii?Q?+LY99mTiQAifBhMEgwQaRua9yFYprC806c1nU1malK92u8lVxR8XccYN4nm3?= =?us-ascii?Q?cv5PP6ftehtRnrWmE52j9f98Vlm7by2oiY91daNSRch32Wrz+rSAv6Hngg/7?= =?us-ascii?Q?QjWxZSHgq/mpPbVbZLjls+g461gzufGRvs828tB4m5cTudzGF+jaf1RGZQ1V?= =?us-ascii?Q?1Yq4GWEQgdDYImDAHNDiTWL0DxqblpF2QXMZe1v02iBhpukaDCDCoS+MU7sy?= =?us-ascii?Q?05CxxtRzAVguz6+XXg8fcU6x79OGcx6XTunV1IcUx0YHX79E+6OIDJXHFFPC?= =?us-ascii?Q?o7iW9msaqJcJP504Va39qiHDYtg7hkbYaAwmuM0p2g66TBqmGKMICYZ7o3jt?= =?us-ascii?Q?iL/2i00BqaE0TvGte7krSN0SSw+QV7qwaONXwl8S0q2axCNbxliKXUwcqc0s?= =?us-ascii?Q?PbCUo4uXD/lvTZtd0U=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3012; 6:brZ9nsuRsrOq5KmSpuuGtCM0V4sPmmdUklsBw5odC9hyrLrpzgCvRZuaVbUHf1udppt9z9vACH2/O7GUiSi37A1hZyq6jMXjZVEyQ7Q4wPbwNVxPdx5QNjxE3ibv+0aOMRMVve+tXoM7MbXEIJeDf5PDeleGjXntuvArnvUYezfn9I23w5Fy1snt4uJLTwmdkZaK49Rdm6O9NJVb+VRhMJzfqUju+SSa0itDDttbWAhGKvrw0yqk0kuPCK2Iqyx12CrNEsNNQLa1thXGIos7ZkDYmh4D9p8I7YyzJoomStVpbQOhOsmjGR5NRr1QP11be80j4sesOMva1Bk6b3Y09Q==; 5:Pp9fw2YGFeP9+MRHfff0bvFe5MHIgrPkGmf3BCX92KWRrKQ+PQmrfRb1s53WUOVfUfh5VwXplSNJUVP09vITSmMeVUrLSmr0o0ORvExToCZlcA68q+ys7F0vu1yQZHrunJFeT5M/b6KgCdZxRdaUKw==; 24:X9QyNlQ6eY3+yAS6VWm0qtudtozFOrpr/FKai/+77nEfvvT3WYnzemgcihe4846ZbW3txqmgiwhLV+gSjcw1GdXWyVmVbCmxtjXud2I+a9A=; 7:7i8VKfrFK2EpPAKeAz/eSwcOkYNveEdMGB7gRFL7lhb+KGQqR95fvAV2qZXoFmAdARuMx/lZE9odW5Qo06g7nYTkDW8QRjIISzD0/AiHdUclIzAeOOtNkukX5ynMfPl+GMu9dIgslK9NOvYSeTCMiF9X7fiez81lA+M4ZRYZ/3BEBtNxtl9B+Wj1GVAk/OPfwrjD2/USP7K41EaVskQCm/X3yMnb3RgSZingVXatgCc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2017 22:53:05.3702 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ea03b818-4e0d-41cb-a096-08d51a68d2a9 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3012 X-Mailman-Approved-At: Tue, 24 Oct 2017 01:42:00 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 22:53:10 -0000 Eric McCorkle wrote: > > Any thoughts on how to validate executables which are not elf binaries, > > such as shell scripts, python programs, etc? > > I hadn't really thought in depth about it, as my main initial goal is > signed kernel/modules, but I have given it some thought... > > An alternative is something like the NetBSD veriexec framework, where Yes, as previously mentioned the verified exec model deals with this neatly, and btw is more efficient than signing individual files - as is needed with ELF signing etc. I think for linux based platforms using IMA we need to generate 20-30k+ signatures, vs about a dozen for platforms using verified exec, verification is also more expensive I'm told. > there's MACs for specific files. That stuff is mostly orthogonal to the > public-key approach I'm working on here, but there's possibly some > interplay. Yes, you use the public key stuff to sign the manifests containing the blessed fingerprints. This is what Junos has been doing for more than a decade. Your "trust" database, might be useful in being able to extend that to general use. The trust model we use for Junos is deliberately very restrictive and thus of most use to embedded vendors. From owner-freebsd-security@freebsd.org Tue Oct 24 00:26:47 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 855F3E2FA7B for ; Tue, 24 Oct 2017 00:26:47 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E32A6622E for ; Tue, 24 Oct 2017 00:26:46 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.15.2/8.15.2) with ESMTP id v9O0QidZ009992; Mon, 23 Oct 2017 20:26:44 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.15.2/8.14.4/Submit) id v9O0QicJ009991; Mon, 23 Oct 2017 20:26:44 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23022.35012.399346.198594@hergotha.csail.mit.edu> Date: Mon, 23 Oct 2017 20:26:44 -0400 From: Garrett Wollman To: Eric McCorkle Cc: "Simon J. Gerraty" , freebsd-security@freebsd.org Subject: UNS: Re: Trust system write-up In-Reply-To: References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <1508775285.34364.2.camel@freebsd.org> <72903.1508799185@kaos.jnpr.net> X-Mailer: VM 8.2.0b under 25.3.1 (amd64-portbld-freebsd10.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (hergotha.csail.mit.edu [127.0.0.1]); Mon, 23 Oct 2017 20:26:44 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hergotha.csail.mit.edu X-Mailman-Approved-At: Tue, 24 Oct 2017 02:08:30 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 00:26:47 -0000 < said: > However, there is a definite advantage to having one signature for a > huge number of MACs. Moreover, as I mention in the paper, the most > feasible quantum-safe signature scheme at the present is SPHINCS, which > has signatures about 40Kib in size. That's pretty terrible if you're > signing each executable, but if you're signing 20-30k MACs at 16-32 > bytes per code plus a path, suddenly a 40Kib signature doesn't look so > bad anymore. It would be pretty great to roll out a trust > infrastructure AND viable quantum-safe signatures. > I could also see a combined scheme, say, where ELF files carry a UUID > which indexes into a MAC manifest. Since packages are already distributed with signatures over the entire package manifest, it would be nice if you could use the package system to feed this. -GAWollman From owner-freebsd-security@freebsd.org Tue Oct 24 09:16:44 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F52DE45F37; Tue, 24 Oct 2017 09:16:44 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D858676FA1; Tue, 24 Oct 2017 09:16:43 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.41] (unknown [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPA id 79D5D9DDD5E; Tue, 24 Oct 2017 11:07:32 +0200 (CEST) From: Borja Marcos Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Periodic jobs lockf timeout Message-Id: Date: Tue, 24 Oct 2017 11:07:31 +0200 Cc: freebsd-security@freebsd.org To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3445.1.7) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 09:16:44 -0000 Hi, I=E2=80=99ve come across a problem with the =E2=80=9Cdaily=E2=80=9D = security job. On an overloaded system with lots of ZFS datasets, lots of files, heavy system load and, to add insult to injury, a ZFS = crub going on the find=E2=80=99s issued by the periodic checks can take forever. They can take so long, I have found = several lockf=E2=80=99s waiting. Is it sane to have an unlimited timeout for lockf? Probably it would be = better to have at least a configurable timeout for each cathegory. It=E2=80=99s really unlikely to see an = overlap for a weekly or monthly job, but for daily jobs it would be good to have a sane default, say, an hour or two. There=E2=80=99s even a parameter on /etc/defaults/periodic.conf but it = seems it=E2=80=99s not used right now. # Max time to sleep to avoid causing congestion on download servers anticongestion_sleeptime=3D3600 The alternative would be to have defaults for a sane timeout for each = cathegory, like daily_lockf_timeout weekly_lockf_timeout monthly_lockf_timeout Thoughts? It=E2=80=99s pretty simple to do and overlapping periodic jobs = are really useless. Borja. From owner-freebsd-security@freebsd.org Tue Oct 24 05:33:40 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4076FE40544 for ; Tue, 24 Oct 2017 05:33:40 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0128.outbound.protection.outlook.com [104.47.42.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C324E70DCA for ; Tue, 24 Oct 2017 05:33:39 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FTTfNAqWcF6pw9Lolcpm/kr6Zoj8D7XV9eNhGyYjIvg=; b=PaOz2O/62Nu0eENt9QYa7KghWlu6IqA3opKSiLLTeIR3w1Yav9l69zCbJlLb0wJrwhpyfZtSaQq8R9jKGAqNqeMBlHEN1L1qVI8DzBXKMZUgf9izXF/qUjAHBhCc7nDLiGHySAr0mSJFq/whx4hx84U12j0ANlPWHzN0hjSU23A= Received: from BN3PR05CA0042.namprd05.prod.outlook.com (10.174.64.52) by BN6PR05MB3603.namprd05.prod.outlook.com (10.174.235.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Tue, 24 Oct 2017 05:33:38 +0000 Received: from DM3NAM05FT010.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::204) by BN3PR05CA0042.outlook.office365.com (2603:10b6:400::52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.178.3 via Frontend Transport; Tue, 24 Oct 2017 05:33:37 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; bimajority.org; dkim=none (message not signed) header.d=none; bimajority.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT010.mail.protection.outlook.com (10.152.98.117) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.156.4 via Frontend Transport; Tue, 24 Oct 2017 05:33:37 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 23 Oct 2017 22:33:35 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v9O5XYNL010613; Mon, 23 Oct 2017 22:33:34 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id E7622385567; Mon, 23 Oct 2017 22:33:34 -0700 (PDT) To: Garrett Wollman CC: Eric McCorkle , , Subject: Re: UNS: Re: Trust system write-up In-Reply-To: <23022.35012.399346.198594@hergotha.csail.mit.edu> References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <1508775285.34364.2.camel@freebsd.org> <72903.1508799185@kaos.jnpr.net> <23022.35012.399346.198594@hergotha.csail.mit.edu> Comments: In-reply-to: Garrett Wollman message dated "Mon, 23 Oct 2017 20:26:44 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <78859.1508823214.1@kaos.jnpr.net> Date: Mon, 23 Oct 2017 22:33:34 -0700 Message-ID: <78860.1508823214@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(2980300002)(24454002)(189002)(199003)(7696004)(2950100002)(47776003)(97876018)(9686003)(105596002)(55016002)(107886003)(6246003)(6266002)(2906002)(50226002)(53416004)(2810700001)(76506005)(97756001)(189998001)(86362001)(50466002)(53936002)(69596002)(97736004)(68736007)(46406003)(8936002)(8676002)(117636001)(229853002)(81156014)(81166006)(4326008)(77096006)(50986999)(305945005)(356003)(316002)(6916009)(54906003)(106466001)(16586007)(93886005)(5660300001)(76176999)(23726003)(478600001)(7126002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB3603; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT010; 1:HPirdidbwqvdAn5hcvDr1ovs82SYRPY6ZqEbsdtt3Ok5HhwaokM/1HcUoeINCQUOMxC6ztM4xQ8wYUvL6VZ+zYeu71Il6b/GOONwGfFpX7z/SNHa/kwxOHqTDtwT8/aM X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: de3d412b-5b54-4750-b5d4-08d51aa0c6e1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:BN6PR05MB3603; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3603; 3:/xae0yO8f+AM27SNTyRbX2Sc/uaiBb9hJS8XqSMPEyZAvp+0MSMkolblDjfvoq/UXL196Qpe/EQX7qX9PStziguwms77gNlvu+lSww0R7a3IVK7qx0toukTBabdZxyb2xTvc1sh4FxfMhM/oYgXhKA1CoV6dPWeX0SpnCz+zoXVmlwKzl32MjpUaOBCbM+YCpVONl9qjE7MRQwmMH0IKMkhWMcBJ75OCKpi6nC/4x2PqMdL6tTNi0i16k/jxowlUffU+0C+EKCIB7GRg9nwUkKd54Ozffbi1cS6rXv8bO6c5iTtPNAi/YkkHzrVyH5O379FkYZ4trmjdJ+RKOvsma6/BoHnX4Ik8LLlNpFm+62w=; 25:x4W0yA+RCFEu/4t7BWBiP3EcG9FJHWT0Hn8gW7C63pt2ok1eBH52Q/Uh4E7qQsL1bxBMrvIBWAmhTKAjwBRT9Z+k8y1ySMuxzmEbUVbvKpL+yk7VD4PQJPZYxYYor8OnfdQTfXUuzByyHPwjOcZGDLXx98CggIlUsAyBmTH8ZUKbxJ8hJGe3+MzTPkRQZqwIOP91hs74B9itIwqUCvyJSz+RnJMuHbssBPQBkZHd23dPfaHb8x3MGS3MbOMWVUtjRWXl6YTh0G8FNC8liNVgscwNLo9I4Tc4lmdzK3kJOUjJEx0U9ZsCMMErC1TbMv6Dn/+SNQ6uLd1HKp3DXsoV4Q== X-MS-TrafficTypeDiagnostic: BN6PR05MB3603: X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3603; 31:kABbQah5c1hp7gKcy3sdo5hNu/F/B0KH/KuU1Yznb0DUKWgpMsYup9X31zIpzLjymAyjZmWZn3PHiKuYiLz0fKaDLQcW37A+vx+Tmee/2kGxaKI3HJnf3Qva58Kdv2MJObGeWkbq4T2ohbaLaOfbN8SJG1RDaywV4tJXdgZF3gaPMEiloxRmqyCVsgD+/4YhAY9U93AnLsFEREYMN7iQy8NqV1fs7epjyrychf8bj/g=; 20:azLwYcA8snl5EC1eVrloyUQnPFoWen28jjjf3j/U6a11qbF9Yajr3EskrW8XZS6P7ntproT9vr5eVAAnbEENr5zGel98biR+aGOL06yRin3YDMNll/4njn/leQdZS5mvgb1OU5Rgjs9+XUKdX1YqtV/ftmOQo83hbEOJSBqNK2c9d3Bd1IiaElkN1XJ5F3FNiPqXlDGa3LclPGHtai7GHuNbATtHlGPxxXniQiR0WJlFt4YQ1sVb3u+bbeB8D9/6G5GfSMWYUHXFVkP2SlNabIPf/lvlrnLqMfN9SxSMsW91DAdkSXifRULhLIaqJ1r0ZS7Xi++BOyRtjO7cFLzHlWfpp5vH7IFt0oEMn/4bFoKwj8mznLNL9tpgmioIiPdCMQ0qQMksst7ZVzJHXj7rbRmQ39OmcY1d4hCiyBGFXbXsfaJkzwpBr4uM2OXQJ7mFKnt9JDDjqCwyYKeKsiPDPmtPE3RejZxeVSMS6eIjfWL7PodCCT/cVj6fTXJ0FNOx X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93003095)(100000703101)(100105400095)(10201501046)(3002001)(3231020)(6055026)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR05MB3603; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR05MB3603; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3603; 4:jpFeGt1KldMlJcz+MPsNCsDZCP3UVL/uQ/80qkplz0gTSY3sTLIk3tiRKSTe2fPBLK9ldW+n6zWjX1N1/bovWbFvaXpb+GETcRODe94LD6XsaS/CBTCvBACOKg54yEl/YtuCUomDH9kA2QVNldHpmM83T+Cbm1vQOH4PnGC7keqtBH6WT0UmNailrDkJi4ES7KYsUvVbyX8xUyht8XdFiExIzu0rkVP0iovmewAdSsQaA/bT20MWqe5PHQJcrv2IJy7GfpKnvS5Ykf15o2ai0w== X-Forefront-PRVS: 047001DADA X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR05MB3603; 23:MI6BTvbXwzPpFWaj/UgJf7Y/ngwvY6IajfLWssnRg?= =?us-ascii?Q?RuMXdYK4J+C5b9RDOMLJfF4/uHMHYTzm6P6ZejL6rk7EPK8NcHklNwg0cLHP?= =?us-ascii?Q?pEkosJVcxs+ARcpOYtflXYYprY7Q7gI0i2SmRNN3OnHhBVlcXwRvdIuM/ph4?= =?us-ascii?Q?c27/+vsjdtTlvwn1G9MYrV6WN5q+NND86rW7JP6Owl4dI44W1TPhzxnuy8f2?= =?us-ascii?Q?W7skuRj6CmcZ2ti7uFche564RKCdG8pIVu4AYXEi4mJ5HnS3ZgfNgx4pJcJc?= =?us-ascii?Q?EYehxfbmGH108bRQKTcIG8rDNYtEXhLNsMNtBXi1k5OT6onzvlx5a03FtpLr?= =?us-ascii?Q?NT3EYqUUfG9PISHTfQHZ29MlnvulVIbXDccRktnGXmquhRFhdTd/bW9sE2CR?= =?us-ascii?Q?fyf9jShC8RfA8p4leB7DyE1Mwh3BLwWp/rinhuV4Qkhcfj672JoYuTRk5lOo?= =?us-ascii?Q?dnwB1SrzMd0LRqUMLVtjs7b5xDw8Qyb7peJypDrT3OvzlX4VlvTI/Bvimscs?= =?us-ascii?Q?WUYBUFfHZLTb7VHW2VXSLtfPrNKBqXUZpHFMDMUQj4aL5lISnOyHMjgcLCq3?= =?us-ascii?Q?lkO4MPsFB6sG25pN8mDEMEA/VioXwrOnpHg6WEc8ZwCQTQ2fWgu51FenCR5R?= =?us-ascii?Q?Jjrfsy6F8Yc/u8SbWFrtirDnqS8EHBWX7QqG40iYzi4BXIbVi60iipLqGFXc?= =?us-ascii?Q?9uCrYZ4aEk/zUF3PEoPT+YfMi8h2mH2340feSQdMEBj2peQhcyb4FADTH937?= =?us-ascii?Q?o5NzmO1YNwyZAeeHCu61bGaltCXWJmht75h7LMUKlJs0u/UEYX4SJkB7rn8r?= =?us-ascii?Q?XVGACO9LDjTKRUym/jM4E3MBE/TILFwxXw1hxoWGFnA21w63AoqaHNPwOmCw?= =?us-ascii?Q?xb5jcvPOi58jJA6KkrE0E1cgT+yU2V3KWwk7E2Pk2avuUjzk8ZaaRqiECS6u?= =?us-ascii?Q?I8bVp2TBSVS6DISxRa5sDqitoNOyuDwL3isw6r84I0mr2DsnMkkYKax06rJ+?= =?us-ascii?Q?pC1ibJW5rdB1SVCpvw8DRM0h7uKRcVJMa73Bc3NSTDUkUWwfwmzb5UEOtt+0?= =?us-ascii?Q?bamU/2a6X8Sv1d2BjZpLhINDofFzEN27jy0LwLr4U36APBzg1Ej/zVOhOW5R?= =?us-ascii?Q?9sWjxE6PMnBU6+6+gRDvcRon8LybEpdL6Xr27GtD2hCdubxXuOZO0zGGo6eS?= =?us-ascii?Q?0C8PHVJefOr+WVOKZ0U2LEPatOBABJnvFr71RBADVrhXW56eKw7LvSR5wivR?= =?us-ascii?Q?NchgXwGOiL2KRpBkBTFL+xoqdd3vh7M/8gpc6vG?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3603; 6:4SkPolwjQZmPMQxi30LmSNmbE9ooeNvAnBZfUHu6fsKaf+cPFiNW0IOgNBjJEpAk8EK8TTlq/09FGyNZLYQ35d8BGGpG396dWk2GULPxCaZeHm51h1cm/EK0ptmJIKWsJt/hRUbs4izf2BdtAr2AOuHh3KWy4whw8RyURhpAwHFPSEyrUO7OwHnVf795JPB6UYoMJC51sTBESxeLD5b3O770qe6Vbp5E0te0e285QY0YzBfYgo8H6OgGMzRL8R3Pid6N4PEMxWPNwlCXi0Sh1VuQ8bijT1TgYaFe/ohFdDr5LU/1B/d6/wYSIqAR+Bsb3R03CkaAjh0f2P8pZT+OPSrjxztVn+FxHuOEj/G31tg=; 5:wNZzfHaPHz1CC7zl5X1xl32X9IgosQod5F+5oMXSeElpTgmXflnPBhPFvRs7FtVbPtSbLLr9kgM5sEe2UGNOb9ASYCqfG0KbSWudmrD3xdwe+8yk5e/tSdI77xNTJAdJaKt1SM5jy86vsWKTC8LQs9OFXYlFhTBAXbS889xu3Tw=; 24:kIUbM+y0Zd3ezmOZCkOQgCo3Z6ewCE7JCLIbHLBhUt8nm0OJxpUHND8yXzMWGurzAHcps52HAjHD8I99rjq1cSvcj3xbIrmYE/yoUQFJ/hI=; 7:Qe0VYI0D3IEeZpX8ZTsjnQsCR/APLDZxV3GtK21XxTppB1w4KHtjTMtq+9SkQPzCFzXXnIi1ZWI87LjmoPliKXa3HMKe7qWwneiysmb+Cj1cnbIE+bCcsJ0BCNKkh2E+C2E9DqQRxoz08BFcdilS3tWzFdrXZK865kQ46MVz80uwRjbgE+6HUanK9++Uo/WdD+5+XR4jHB1n1cArabM/7oRQbfWkRUEZut6LxgsMLJqONi5Mkf9peelQzmEkyaHq SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2017 05:33:37.3437 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: de3d412b-5b54-4750-b5d4-08d51aa0c6e1 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3603 X-Mailman-Approved-At: Tue, 24 Oct 2017 10:10:57 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 05:33:40 -0000 Garrett Wollman wrote: > Since packages are already distributed with signatures over the entire > package manifest, it would be nice if you could use the package system > to feed this. Yes, that's what we do in Junos. The Junos package system relies on veriexec to verify packages and their content, and thus automatically feed manifest contents to the kernel, which renders the content executable. Eric's configurable trust store, could allow the above to be more widely used. In Junos the trust store is burned into the apps that need to verify things - which is great for us but not what you want for general deployment system. But it's hard to do things like this if they have to be optional. From owner-freebsd-security@freebsd.org Tue Oct 24 15:06:09 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE007E50165; Tue, 24 Oct 2017 15:06:09 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80F7A632AD; Tue, 24 Oct 2017 15:06:08 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.41] (unknown [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPA id DCD459DCDBF; Tue, 24 Oct 2017 17:06:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: Periodic jobs lockf timeout From: Borja Marcos In-Reply-To: Date: Tue, 24 Oct 2017 17:06:04 +0200 Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alan Somers X-Mailer: Apple Mail (2.3445.1.7) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 15:06:09 -0000 > On 24 Oct 2017, at 16:41, Alan Somers wrote: >=20 > On Tue, Oct 24, 2017 at 3:07 AM, Borja Marcos = wrote: > Are you talking about the lockf in /usr/sbin/periodic? It already has > a timeout of 0, which should prevent overlapping periodic jobs. Or is > there some other lockf involved? Without knowing which lockf you're > talking about, I can't understand your problem. Sorry, my explanation was awful now that I read it again. Yes, I mean = the lockf in /usr/sbin/periodic. And no, I didn=E2=80=99t mean that jobs overlap (certainly they don=E2=80=99t = thanks to the lockf) but they can pile up. Today I had a machine with three daily jobs waiting to start because the first one = had been running for four days (a combination of lots of files and datasets, heavy system load, ZFS pool almost = full=E2=80=A6)=20 The problem with a timeout of 0 is that it=E2=80=99s unlimited. In case = something is wrong you can end up with a growing queue of daily periodic jobs waiting to run. Imagine you have a very high system = load for several days and for some reason the daily job won=E2=80=99t complete. Next day a new daily job will try to start but = it will have to wait for the first one to finish. And so on. The proposal is to replace the =E2=80=9C0=E2=80=9D timeout for lockf = with a sane timeout so that it will attempt to run it, but give up in case it can=E2=80=99t be done in a reasonable time. The timeout = shouldn=E2=80=99t be long actually. If periodic must wait in order to start a job it means that you have a serious performance problem and = it=E2=80=99s pointless to keep your machine doing =E2=80=9Cfind=E2=80=9D 24/7. Given the nature of the periodic jobs I don=E2=80=99t think it should be = a problem to attempt to run them in a best effort basis rather than guaranteing that they will eventually even if awfully late. I would add a configurable timeout for /usr/sbin/periodic. I think = it=E2=80=99s better done with a different variable for each=20 class and their default values can be 0 so that nothing changes. daily_start_timeout weekly_start_timeout monthly_start_timeout > The anticongestion_sleeptime variable is unrelated to lockf. Understood, I stand corrected. I assumed it was.=20 Hope it=E2=80=99s better now. It=E2=80=99s pretty easy to do but I=E2=80=99= m interested on the opinions on this matter :) Thank you! Borja.= From owner-freebsd-security@freebsd.org Tue Oct 24 15:31:53 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 572D8E50C83; Tue, 24 Oct 2017 15:31:53 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BAB1643D2; Tue, 24 Oct 2017 15:31:52 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.41] (unknown [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPA id 777009DCA56; Tue, 24 Oct 2017 17:31:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: Periodic jobs lockf timeout From: Borja Marcos In-Reply-To: <1508858729.34364.32.camel@freebsd.org> Date: Tue, 24 Oct 2017 17:31:48 +0200 Cc: Alan Somers , "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1508858729.34364.32.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3445.1.7) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 15:31:53 -0000 > On 24 Oct 2017, at 17:25, Ian Lepore wrote: >=20 > No, lockf -t 0 means to exit without waiting, with status EX_TEMPFAIL, > if the lock cannot be acquired immediately. In light of that, the = rest > of your report/request doesn't make sense. Jobs won't stack up, > they'll fail if the prior one is still running. True! Then I don=E2=80=99t understand what happened. When I saw several = processes waiting I assumed it was an unlimited wait.=20 My apologies, I need to look into it more closely. Borja. From owner-freebsd-security@freebsd.org Tue Oct 24 14:41:38 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84BEBE4F99C; Tue, 24 Oct 2017 14:41:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 093F4307A; Tue, 24 Oct 2017 14:41:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id a16so24281098lfk.0; Tue, 24 Oct 2017 07:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=BbNVDhf5LnwKiqD7ODMzM+u2vvAdu2vY9b897WxS6Uk=; b=IQXAT5om+/zRHP+DRogUPy1dPK5juWJBqBamokzJXPpatfuGkfifKgHtO8MHXk/OX1 3bxXyvxBNfKw948qPFkNHk0ty6EtNWtxMNnEdBTwdmnPFl0CawzpqMlFxe4znUhqoD62 mNnWMzOQqbObJrp6IVfJve41BxjocZ5ycJ4NbjTfCzy5zZuunLqvNF3rRJK5CKLMx77v bYoL2e1Y8dOHpMC4vHO/IJge12pr2AoRETq3nQAUHkoQFA8w2ATECKTzk3hWZ4pw2LsJ Hr1UnMWVFYoIh6dLQkfkha9voZtWf92sqJ/LqwkmiYOi5crzT99z0HI8XqO8qHvaOyCw NqDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=BbNVDhf5LnwKiqD7ODMzM+u2vvAdu2vY9b897WxS6Uk=; b=mOiYPRLSCsYHzQySvCx3t3sS+rYK6nz8vOlIcxg/0d6hM3+fN8b4OwYI5giOwuG1TW OLGFXdP2CwlmJHRf6P8TCgEyjD0u+PH7LcDmMaYA1cIQJJ6qjqI7EOVdakZKWOPPfZJI y2dRWAWG9nT4fWFPXj1twfFi0bnTJsRKJ9cWUPxRCISUrYtuNAL568jJK8KdYrnSHlTF /uChKTbKkUzt0BxNizSAmX4wZWxm8mKLCY6mnvI+w4qy78RAMYI+zpxaUc53rzv4fBuC ZPMyOvhg9fyOiKJAAFSKiN64mmkNrPFix+6jnrCih0zHiVEbR9DigPwPvQa1FFUf5gQg 2mIg== X-Gm-Message-State: AMCzsaVuPPrpcOjYI7IrqSmQB9KwF82BjpLoiyqgmNDrfRiTHd0T2dGj jGcvpHSWuVwNrGPUTCRuy6WX1/Kjhvfp2mqNGeY= X-Google-Smtp-Source: ABhQp+T2jw96XXtsJkw6l2VDgdHlRdPwLvIbsmXzKxLImq/z2aI55uni8bQGogqIjM0+Bdf5YWYc9VZTiGx9Bf7PAbo= X-Received: by 10.46.20.11 with SMTP id u11mr7092183ljd.38.1508856095941; Tue, 24 Oct 2017 07:41:35 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.93.24 with HTTP; Tue, 24 Oct 2017 07:41:35 -0700 (PDT) In-Reply-To: References: From: Alan Somers Date: Tue, 24 Oct 2017 08:41:35 -0600 X-Google-Sender-Auth: pShcwbTzR9lrwE_EmYzWXwTvQz8 Message-ID: Subject: Re: Periodic jobs lockf timeout To: Borja Marcos Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 24 Oct 2017 17:28:22 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 14:41:38 -0000 On Tue, Oct 24, 2017 at 3:07 AM, Borja Marcos wrote: > > Hi, > > I=E2=80=99ve come across a problem with the =E2=80=9Cdaily=E2=80=9D secur= ity job. On an overloaded system with lots of ZFS datasets, > lots of files, heavy system load and, to add insult to injury, a ZFS crub= going on the find=E2=80=99s issued by the > periodic checks can take forever. They can take so long, I have found sev= eral lockf=E2=80=99s waiting. > > Is it sane to have an unlimited timeout for lockf? Probably it would be b= etter to have at least a configurable > timeout for each cathegory. It=E2=80=99s really unlikely to see an overla= p for a weekly or monthly job, but for daily > jobs it would be good to have a sane default, say, an hour or two. > > There=E2=80=99s even a parameter on /etc/defaults/periodic.conf but it se= ems it=E2=80=99s not used right now. > > # Max time to sleep to avoid causing congestion on download servers > anticongestion_sleeptime=3D3600 > > > The alternative would be to have defaults for a sane timeout for each cat= hegory, like > > daily_lockf_timeout > weekly_lockf_timeout > monthly_lockf_timeout > > Thoughts? It=E2=80=99s pretty simple to do and overlapping periodic jobs = are really useless. Are you talking about the lockf in /usr/sbin/periodic? It already has a timeout of 0, which should prevent overlapping periodic jobs. Or is there some other lockf involved? Without knowing which lockf you're talking about, I can't understand your problem. The anticongestion_sleeptime variable is unrelated to lockf. -Alan From owner-freebsd-security@freebsd.org Tue Oct 24 15:25:38 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD4EBE508A1 for ; Tue, 24 Oct 2017 15:25:38 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6680863E82 for ; Tue, 24 Oct 2017 15:25:37 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 940d5056-b8cf-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 940d5056-b8cf-11e7-a893-25625093991c; Tue, 24 Oct 2017 15:25:35 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9OFPTfG001285; Tue, 24 Oct 2017 09:25:29 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508858729.34364.32.camel@freebsd.org> Subject: Re: Periodic jobs lockf timeout From: Ian Lepore To: Borja Marcos , Alan Somers Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Date: Tue, 24 Oct 2017 09:25:29 -0600 In-Reply-To: References: Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 24 Oct 2017 17:28:38 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 15:25:38 -0000 On Tue, 2017-10-24 at 17:06 +0200, Borja Marcos wrote: > > > > > On 24 Oct 2017, at 16:41, Alan Somers wrote: > > > > On Tue, Oct 24, 2017 at 3:07 AM, Borja Marcos wrote: > > Are you talking about the lockf in /usr/sbin/periodic?  It already has > > a timeout of 0, which should prevent overlapping periodic jobs.  Or is > > there some other lockf involved?  Without knowing which lockf you're > > talking about, I can't understand your problem. > Sorry, my explanation was awful now that I read it again. Yes, I mean the lockf in /usr/sbin/periodic. And > no, I didn’t mean that jobs overlap (certainly they don’t thanks to the lockf) but they can pile up. Today I had > a machine with three daily jobs waiting to start because the first one had been running for four days (a combination > of lots of files and datasets, heavy system load, ZFS pool almost full…)  > > The problem with a timeout of 0 is that it’s unlimited. No, lockf -t 0 means to exit without waiting, with status EX_TEMPFAIL, if the lock cannot be acquired immediately.  In light of that, the rest of your report/request doesn't make sense.  Jobs won't stack up, they'll fail if the prior one is still running. -- Ian > In case something is wrong you can end up with a growing queue of > daily periodic jobs waiting to run. Imagine you have a very high system load for several days and for some reason the daily job > won’t complete. Next day a new daily job will try to start but it will have to wait for the first one to finish. And so on. > > The proposal is to replace the “0” timeout for lockf with a sane timeout so that it will attempt to run it, but give up in > case it can’t be done in a reasonable time. The timeout shouldn’t be long actually. If periodic must wait in order to > start a job it means that you have a serious performance problem and it’s pointless to keep your machine doing “find” > 24/7. > > Given the nature of the periodic jobs I don’t think it should be a problem to attempt to run them in a best effort basis > rather than guaranteing that they will eventually even if awfully late. > > I would add a configurable timeout for /usr/sbin/periodic. I think it’s better done with a different variable for each  > class and their default values can be 0 so that nothing changes. > > daily_start_timeout > weekly_start_timeout > monthly_start_timeout > > > > > > > The anticongestion_sleeptime variable is unrelated to lockf. > Understood, I stand corrected. I assumed it was.  > > Hope it’s better now. It’s pretty easy to do but I’m interested on the opinions on this matter :) > > > Thank you! > > > > > > Borja. From owner-freebsd-security@freebsd.org Fri Oct 27 00:29:10 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4B41E56CEF; Fri, 27 Oct 2017 00:29:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 918E86F945; Fri, 27 Oct 2017 00:29:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 7E7A912D3; Fri, 27 Oct 2017 00:29:08 +0000 (UTC) To: "freebsd-arch@freebsd.org" , freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" From: Eric McCorkle Subject: Crypto overhaul Message-ID: Date: Thu, 26 Oct 2017 20:29:08 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 00:29:10 -0000 I was going to wait a bit to discuss this, but it's very pertinent to the trust infrastructure I described earlier this week. There was a good bit of discussion at vBSDCon about a possible crypto overhaul. This is my understanding of the current situation: * Userland crypto support is provided by OpenSSL, of course. My sense is that there's a general dissatisfaction with OpenSSL, but that there's a nontrivial effort required to liberate userland from it. * The kernel has sort of two crypto APIs: crypto and opencrypto. The design of these APIs seems to be something of older hardware crypto architectures and export restrictions. This is difficult to extract from the kernel (and say, embed into the boot loader). * BIOS geli pulled the AES implementation out of opencrypto. This was due in a large part to the size restrictions on BIOS loaders. * As a bridge measure, I've introduced boot_crypto into the EFI loader, in order to support GELI. At vBSDcon, there seemed to be a consensus that this situation is too fragmented. Moreover, it makes life difficult for anyone (like me) who wants to do crypto-related projects. A couple of options were discussed at vBSDcon. The two that seemed to come to the forefront were BearSSL and LibreSSL. There seem to be some advantages and disadvantages both ways: * LibreSSL is mature software with staff and support from another BSD (OpenBSD), they've done some really good work, and have a definite long-term roadmap. I'm not sure to what extent it could be easily embedded into a kernel and bootloader, though. * BearSSL's design seemingly lends itself to acting as a userland, kernel, and bootloader library. On the other hand, it's new (which means it will need to be reviewed by crypto experts and thoroughly tested), and has one developer at this point. I think it's worth discussing and investigating these options further at this point. From owner-freebsd-security@freebsd.org Fri Oct 27 01:34:07 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24344E5846F; Fri, 27 Oct 2017 01:34:07 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0119.outbound.protection.outlook.com [104.47.37.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA29371779; Fri, 27 Oct 2017 01:34:06 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=a3iXHARXdmkUNqnkCZOFCSt/nCVDC/ON2liKbDUhM3c=; b=X0lNtI/r3h9XlbrMX24PfXZq5HXzEYZ8+FxxCuaxRAJhWQN1ZifHIe1Yv54cRMie+GGoAFycK0OUcVrkK4db82bcGjlEjxaSvetcSj+428UqD2qz0XOLSWh3rGfo5zzhPdg5SJxbqWRpHLkT4xiUL57SWnr810KaG/qOAuj51ao= Received: from SN1PR05CA0033.namprd05.prod.outlook.com (10.163.68.171) by MWHPR05MB3613.namprd05.prod.outlook.com (10.174.251.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Fri, 27 Oct 2017 01:34:04 +0000 Received: from DM3NAM05FT023.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::203) by SN1PR05CA0033.outlook.office365.com (2a01:111:e400:5197::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.197.4 via Frontend Transport; Fri, 27 Oct 2017 01:34:04 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT023.mail.protection.outlook.com (10.152.98.133) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.178.5 via Frontend Transport; Fri, 27 Oct 2017 01:34:04 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 26 Oct 2017 18:33:36 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v9R1XZF8009830; Thu, 26 Oct 2017 18:33:35 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 38E34385568; Thu, 26 Oct 2017 18:33:36 -0700 (PDT) To: Eric McCorkle CC: "freebsd-arch@freebsd.org" , , "freebsd-hackers@freebsd.org" , Subject: Re: Crypto overhaul In-Reply-To: References: Comments: In-reply-to: Eric McCorkle message dated "Thu, 26 Oct 2017 20:29:08 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11244.1509068016.1@kaos.jnpr.net> Date: Thu, 26 Oct 2017 18:33:36 -0700 Message-ID: <11245.1509068016@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(2980300002)(24454002)(189002)(199003)(5660300001)(97736004)(7116003)(47776003)(221733001)(478600001)(6916009)(69596002)(2950100002)(68736007)(23726003)(356003)(46406003)(117636001)(7126002)(54906003)(2906002)(50466002)(16586007)(2810700001)(316002)(7696004)(189998001)(8936002)(86362001)(81166006)(97756001)(50226002)(81156014)(8676002)(97876018)(305945005)(107886003)(3480700004)(50986999)(77096006)(106466001)(6246003)(105596002)(229853002)(53936002)(55016002)(53416004)(76176999)(6266002)(4326008)(76506005)(9686003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3613; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT023; 1:tutf51ZBf3DBn0F0xdAT0T/O9bcsviwMU/IwWo/y6qhBYR4P37n4rgyf3/2x6ibpXKk8CSgChHmurVaKY0FSkvj4+KbYWH7Uj3QwU+6jsTBpxQs1OBZY184Mg+oXchZL X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b4ae7ebb-f6c3-4d14-ba9d-08d51cdacf2d X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:MWHPR05MB3613; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 3:SzEQvmnn/fXrpC31dGsjM4bqJkTqH4Jx0RkJmW8IQGfaUNeh8gO2BfcYGOF4osg7x5EBULnG9aj3vyMQIhrfcrMBe9IpmouHL4dE25miyBjAW2Kp86Yn9k9X7edqnXxSmjzkjcPr+xcE/uki5MmNspiiQx9EQi34yvWNMp9mdqy/CShhrbyq/tk1DCsxAJpw6g0jYbaJSkUj8syToe7KhfMMn1cUQgIpXDnQP5Bdss6TovnE+F6qkiR1snb23PxSyzS1CY7txSWlfmKd0V5o9GkqffSU7gjUHbgpZyoocbsMCWLdv9FtGOHItSdKkqyCb/XPHYyq201NMVrAiTve5PQH8uEeMMmifwme2rKS4G8=; 25:lQhz+c/mv32WIvtxxESEVTVTHRmUku9r9D7R/3OWQ+wMM3P+q9nYj0nCBJwsyTl7VAVfFdcQdGd/5GLGhy4zuYCsRuPym+yKXr6VZh275tnQIORecVd3+Tg7ddb3ANzm3xXs79GT9LQ2KgiN3NDddhZWt8gLoXYI+zOIIN27f71WStb1Xm1VQAEr4FCLUqgOY3x52ZCnGnF2AFAV5iSqLTE30qpU6BEOJxjYja3V8zCuSmd97vFR+s9INFQ3e8hryjoHuQgO0mHYiq9NzjX73uYHRenBj7fW7042R+ekWkDMGvWk6XQj65nEfYg9ZzDBWFrd85ArykxkSMdoFAqgVQ== X-MS-TrafficTypeDiagnostic: MWHPR05MB3613: X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 31:Kn/f9N8byNpr+g9u5pLxswEVJgp4SDSx+GDLICiDnwCQflvco3QZUz41RWObnl6MONd/efr9FbdHciCmX7H8/uLlUN2d5Vx7UMqPP3FlvPUwrDP8yLb60bKf2XqW4I0z5Sv3KPtYl9puKuXQdyRWAlMEHNzrdRdq4F5HpY1WqYE6iKrQa9weQpC0QcdMOWH0p+zGJQGJx/VI/8AXCG5r/mmoR5ZWisc6QuKVbdat3AI=; 20:PUw8E+kC0Iga2m3h4+vTtbyqzTphqpXxP+kxwB13EyKhkzskp8yn7AK05PrVpS5tnwFotMyRo7AVqNoWs6xaSvEH6Ut1wmkJXRzYfqTBl7Y4Ga5AugJoyPdd1DBbK6mVZ2BC3oB8AmPARIjpZny4rCZutK/KTHJUfaGIYwuTNJlnot1h7jOeXvlv1F3yR2ZP1zQivQgLQCKl56VsrbEo8Aq1RJqby2Z/OJj6sHtf5KcjpP9xES3yIaAKBXByBtJ+/uuqxJjSjuT+v5ckr6Bzk8w1eY80Wm07GtF9FDWMlUiHHokr+bvQ7/MM7yibQIIaobhT+cwDkMAOxTm2ZL6XoorClCx2yt4R0+l+rbQojqTh1/idOukNB0dy6EduVvGTkERlB7o2bL82z3NSf4YfgkSR1nB5Dgsv0chVV1EZUn3XO3AAFCcoA5extp+c35JayMJfP8kFrT1lKpT4aLRzQKRNadtcj4SJ5lqGibpUnjpZz5SuYP2Hqv7zwJb01kRs X-Exchange-Antispam-Report-Test: UriScan:(244540007438412); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231020)(100000703101)(100105400095)(93006095)(93003095)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3613; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3613; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 4:z5SzSYLZNbGliA4tOWtpS6H2o/BhYnOzmwAkqMA30ksXrpYkalZ3XQtnZtESvUwiIViPDszqNGEF52rVBtCmySlLnOuMaSYtAnTgYfrOgS4MBnuw/3+zxb9FNofN9/nBZlYlSelkCEOcfJUsBfXmrItvS73DmysE9cwtkNdpj42H31W/ghph0FaOeP65v/2SFxw4GM9NlRNPo16ijLhhIpBcY2UkirBxCeLFmwRN4zBt23bn13tgHT8VRLtt8xF+vNPWTqVQsKNx3ogvzW4AMQzbj+DlrXDOmck694FDa5WNjxJK8kn8Bv6v50OWT6JS X-Forefront-PRVS: 0473A03F3F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB3613; 23:Ko5e/wNIhH8wAt3VzWt+BZHv94qjBfpaUMs45UkA2?= =?us-ascii?Q?zKKgOWUwk0cEq+B07YDsH4vRFbHxFxSe21wr8Pd4OUGw7qwyYQKOykkIC8Ny?= =?us-ascii?Q?MWZjPPAZKR2SoK2vSFHlVYtH9+VTS0+XAxWqDNWVOTpTW8NN8Nifc9Gc4rNR?= =?us-ascii?Q?fraLNGikDRyXJL3xuHnEWL32sEwFbVE2tmPuhH4GFZUZOVXAKxGMfMPkT/LS?= =?us-ascii?Q?x5loI6zuvUQtNPIvpZAp23zGqF0bSV0e7Nns2XNFdXNVpowBJ1Be2W+qNtC9?= =?us-ascii?Q?xKRz3GWQx0E5J4+I5kcY3GzVilKP884aRbjjxQRdoJba9aARgZLf7piRJZCA?= =?us-ascii?Q?fcRioLDwEa512+bomKDHV78kpje00r3XGeMg8OR/7OOtKVjnGzmmzpICUZnQ?= =?us-ascii?Q?SrYQzio0wfeTRdbEbwR7BDZYKmmjft4w0RTV3WRWlLGCU+/mMBTYmHiGhzWg?= =?us-ascii?Q?PmH43+zUKmMbhSdLLUcEIhE6dUC+/ttN78zvz2YkapU1umJG7lfqfuwwCNSN?= =?us-ascii?Q?zxdb1K0nX/zGTOWJ7r7XnpFxB1kSuFpZUnTLhilRSjlmKXZGAMFmP1+0JaXC?= =?us-ascii?Q?7SzGNxrWe9RQZnnmQFNu/lcwv9F4eDy5WriB/QNC8+3f47mrVDsO8cXBWrJA?= =?us-ascii?Q?NgRm1AHhksLYa8J7nGUiLg9zVOi62hFwG9x6FSeeW2Wyafktde5Rr677BmwK?= =?us-ascii?Q?ZsnxHmonrfcNcKSuzhJuOPeXR5uR6rqK0ziUh58V7ch6MYvslD6gJ2rYuyar?= =?us-ascii?Q?HD5iiNCp1SPb2OLT7QfcIUhB67CreRvcdMfzNsvHsfwtrZTaLsHozYrN8uBZ?= =?us-ascii?Q?chIS3J7t0UgjpChX9VkkizrbogFonPCDg+VucDz6+Sk+mHGsSWdFRNhA9j4Y?= =?us-ascii?Q?uYLaIJTIqfwAhU02XkM2fK+P02dcnchKe82yNG2mhNiXBOI2h4UTzwWt9Wrf?= =?us-ascii?Q?QXBZuy4BzVEdCo1OB6qF99MMjTvM3EFbWWtjmzzVcxSnuOKbhr2pF13OX5zk?= =?us-ascii?Q?cCszbZA+06VYnpXrKA8wHyAYSaqCHM6htW0P+HlvYlJ77y8j77M9etlI+Y8T?= =?us-ascii?Q?61sRDOv8HRyg89WKqW9ORp8SgO5YKxnB2Jk2gpH6KtkZkXaU0nSHbh2/3oO9?= =?us-ascii?Q?OP1/x3ze+NY2HUbgFf5DQ5NZsyWjqnvsrANDPRsuq/cM+e8LiZzHdVwXORzO?= =?us-ascii?Q?Dnji5/xeUeYJ5b00CDDMvZwX9xfDCkxHFt1F7B7UhUw97jQKDZ1b0gsagK6f?= =?us-ascii?Q?P7XX+5znwZ2aj8lQQtNe49NHaGb9e8xfjNGcrw7CG8msttbMqs1TatKT1mWD?= =?us-ascii?Q?7cFcSwQK90DVX33APvEgMk=3D?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 6:PpuNmw3FLXvvQTF6B+OBJNII8byauNTCcil+B1EJpKVweZkrSTBdmn1F7dUvAbZKxtkUsjBxmajbBVYMebr2aB0XPHL0cKKCF+qEYE74FatvCYzhWYcuoMeS3vmOPk3KdEjj5eVQXQRQwvLYbMBI3HGDlrajayQ+/97g9SmFjwdeAvLlSe8xquIBYB7MT+KU/PHtulotx8Nf3KG/qmN9fuu/roDRa3jTLfaQ/oDhmHtfP7R1lO+e/z+zSZXzUjYVsPOBDsc8vb/vZ5SZWVEcZ7W+EJNAIZzDy4moyNkPXaFyThngKnqQelvE77LGzRf86USncECv1htPEnl8zIM/nRhH3BANSDKGD800e1o5vA0=; 5:RVssx7qCRizlvs9mTrsy66CVfbWz9Lv3SAlD1Cs41Mq/+7810TmlKAYuAyx21/6roOiu8B2wkr4lOG+Ma98gl18Cq/+oRAmLxNshpT4sXE/wPbdHOCFLHP0O2IncwM8uKAQ2Uiy1NVUVrBIwckNhoQwCZfOJf/HclE0AsqvJ8Ow=; 24:XNXfxkBua9xiLjH5t1qigWXLKyeY92sK+RUCgN4tprD3wHKNykFOaORsyXsJ6osWAHTeqY+RiCCY+1hl/6GmtBJySx6rNferidg9iv0rrpE=; 7:VwCmypqcCq6N/UeW+gGvaVq4LzIGFJh8IHto0+/K7Zrl7yUXERY1u1yIKfn8xQzm/SGgIje829+g6eMXJiAxxt9QewSXupq+k60cGUTzp9DSoMEMDPHuMehcvqsvNa3AL/tp5HOcjNMOqEbpevP7qGJcUlF0VSyatQvKR4TBCh+SMoMn7EtuKEsYYWGEQ9CCxhKMNOVkNds99p/Z+mljby+xtX/WsUNiGexTmCMabMthD2FPiLXiPNIb6000Wbim SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2017 01:34:04.3996 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b4ae7ebb-f6c3-4d14-ba9d-08d51cdacf2d X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3613 X-Mailman-Approved-At: Fri, 27 Oct 2017 02:38:45 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 01:34:07 -0000 Eric McCorkle wrote: > * BearSSL's design seemingly lends itself to acting as a userland, > kernel, and bootloader library. On the other hand, it's new (which > means it will need to be reviewed by crypto experts and thoroughly > tested), and has one developer at this point. BearSSL is indeed very new, and review by crypto experts would be most welcome. It works very nicely though for verifying signatures, X.509 cert chains etc - everything I needed for the loader to do verification of modules. And it is *tiny* I think all the verification stuff added about 80-90K to the size of the loader. The author, has been extremely responsive and helpful, nice to work with. The API is very different to OpenSSL so I would not contemplate trying to use it as a replacement for userland crypto lib anytime soon. But for the loader (and kernel if needed) it could be a very good option. FWIW I did not need to touch kernel, since I have the loader verify the kernel and the mdimg it uses for /, thus init etc are also verified before we pass control to kernel. From owner-freebsd-security@freebsd.org Fri Oct 27 10:00:05 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6067E3ECF3; Fri, 27 Oct 2017 10:00:05 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 9F9CC8301F; Fri, 27 Oct 2017 10:00:05 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: by mail-qk0-x242.google.com with SMTP id x82so7643395qkb.12; Fri, 27 Oct 2017 03:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ABB/QRnvrZxvpvJSimeFkXxTRdOwGsYQrgRenYUIXsU=; b=cnn3YlwyP1lqjoSGY8S0FvBqbWOg/d3l+RR4SvMT9VNX/yX6LLVGPSHLa49nutB1Ww Vfyz99hXvIh8qbwh7Pa+6tB1/F4wDAqhN8fefS9xQeyIOKO8W24Ea1ULjMpExlfU8bgg jxLUeE0P8XIXk1niwtN3FhguL8LkNkUSt4F8CkF8CsajN+YTKxLZrFB1cUemSbt8P3H3 DkOju03Yo5EqnEr9qT/Z4YnsTb5VZATRosZdU4cV2nXZ3IQq/C7MNay0WEaYC+9qNu9U Bza8we7Hg66eJTN59ZJ2nsWIiPTD5QTsAeZ/A7/0lptMyGgX10B6zssl/E5hYMA7l06m Yrow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ABB/QRnvrZxvpvJSimeFkXxTRdOwGsYQrgRenYUIXsU=; b=h5EasdhZsncC0txuUuJbZaxqbldVKeTDyOI0GozeWYQwXKm3rUcRakVMwvW9LUfzgU IodZXyRkjizCKVd8m6XJ/MeXRAhKN0NWwSBvj1LTajnjXhLUMKfPJGydsLQ0QFEsuNfM x8gGruq26LlhXhrME0VtTPYlCJNkfbX3+CIgPLCA9ocvfp7+AhZiAlxVsFB2nc4JFK4p C9y/Hl0DyMEssg7efx7vJiGnLZTmQMELobsRW6tPooOhm6WD9+ryNa7Bm0oUXpAkjxwz OjC3iRjtpLJ15QxRpDEntm9CEtdpil2X5vpD3DPgWp0dqbwSnU15yJfObXVGzeJHswj4 P5Pw== X-Gm-Message-State: AMCzsaWb+7Ejor36Hr/Z5fT/R28jwakrUlKIHoKyd2V6S6s0CMMq/hQU imrLDG42JrFcL2YytM0hkx3PM3JS6Q5zHKm4dww= X-Google-Smtp-Source: ABhQp+TFY4158zoi+PFWoy+2+Vye0wZzzgWtZ7ALn8ha6AlCkVnip5h8K5fB01OdXzwOEPJ57u2eMoQVYHGwJXKdx/0= X-Received: by 10.233.216.199 with SMTP id u190mr11795910qkf.203.1509098404774; Fri, 27 Oct 2017 03:00:04 -0700 (PDT) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.200.22.174 with HTTP; Fri, 27 Oct 2017 03:00:04 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Fri, 27 Oct 2017 11:00:04 +0100 X-Google-Sender-Auth: q78TFe_MWnegvzwZJvlRaq7Odfc Message-ID: Subject: Re: Crypto overhaul To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Fri, 27 Oct 2017 10:45:32 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 10:00:06 -0000 On 27 October 2017 at 01:29, Eric McCorkle wrote: > I was going to wait a bit to discuss this, but it's very pertinent to > the trust infrastructure I described earlier this week. > > There was a good bit of discussion at vBSDCon about a possible crypto > overhaul. This is my understanding of the current situation: > > * Userland crypto support is provided by OpenSSL, of course. My sense > is that there's a general dissatisfaction with OpenSSL, but that there's > a nontrivial effort required to liberate userland from it. > > * The kernel has sort of two crypto APIs: crypto and opencrypto. The > design of these APIs seems to be something of older hardware crypto > architectures and export restrictions. This is difficult to extract > from the kernel (and say, embed into the boot loader). > > * BIOS geli pulled the AES implementation out of opencrypto. This was > due in a large part to the size restrictions on BIOS loaders. > > * As a bridge measure, I've introduced boot_crypto into the EFI loader, > in order to support GELI. > > At vBSDcon, there seemed to be a consensus that this situation is too > fragmented. Moreover, it makes life difficult for anyone (like me) who > wants to do crypto-related projects. > > > A couple of options were discussed at vBSDcon. The two that seemed to > come to the forefront were BearSSL and LibreSSL. There seem to be some > advantages and disadvantages both ways: > > * LibreSSL is mature software with staff and support from another BSD > (OpenBSD), they've done some really good work, and have a definite > long-term roadmap. I'm not sure to what extent it could be easily > embedded into a kernel and bootloader, though. Have you considered BoringSSL? > * BearSSL's design seemingly lends itself to acting as a userland, > kernel, and bootloader library. On the other hand, it's new (which > means it will need to be reviewed by crypto experts and thoroughly > tested), and has one developer at this point. OpenSSL includes (and is used for) lots of crypto that is not used in SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be used to replace all uses of OpenSSL. > > > I think it's worth discussing and investigating these options further at > this point. > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-security@freebsd.org Fri Oct 27 12:45:33 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B08AE4419D; Fri, 27 Oct 2017 12:45:33 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 1E16963F8B; Fri, 27 Oct 2017 12:45:33 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by mail-wr0-x230.google.com with SMTP id o44so6043427wrf.11; Fri, 27 Oct 2017 05:45:32 -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=wYLv4djExMSBeIpSe7YpemDIhoUVP7f45OwUe9MccpI=; b=b4/MozBvDnC7sRlbCexp9guO6CAagXBYVETqwLchtOkFSuBpeoNT1TxU8P1Zj33Py4 IJu2baQA/2BaUbQXF359+yO0eAIhGw5im3e26hYonSoQKrOzWE1YWh76DWkNChJg3Pc+ m/wCCdE4Jhmij0Q8cBUXn4v3MS2L+PcJJlA57AknbyNjEbtrb8HmjHmqQ8VI8bLHw2Cx EZ90MIwitpQqDoWmc6I4A+OQUG8s091Jl3XPn8g6ZWy9lsBXcfa4TbCb5sJjt3ZHUVbQ 9y+FbidTbEm9geEdZmdbDgWx+G5EDWddXU13gZaiZN9isV298GkoofDsD1O7I/yg1Ig+ lHkA== 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=wYLv4djExMSBeIpSe7YpemDIhoUVP7f45OwUe9MccpI=; b=BxQ1U7UdcwJ9JXQzu9G++iNrEQZDVsQ5PYM9Oidzs+ye8AlfJ3OSW0EIGeqc88oQqg 2uAJmk9J/gUC7+WKBW0gvWZiB35tVB7z4TaM3tVa6aiNxGU6v0z9mTnlvFBhmHxcUS5s DdlCk7HfgFrDxtPl1YNx/uAPm6Ew9HyQsYwxm8XhRrznZVATG7bSuwvme3AWyzHWop72 86YlGYhmt3nXTL8Vm87kFv/Nk1B5HIbe6gQsQPI6Bvi9TJ3MhVOKjVaSwUdrPWACQWLt PsDohNV6axs/Uv7HUCpDRvW6s5arsaKzdUCiXQylzhXuk74xta9oXhbtDamGaqjbdxDG GucA== X-Gm-Message-State: AMCzsaXXlyUZcuq0p3WEejN4HThhg8OtNkUuclCbpfHI9MS6q65AGM/r n2505duXdpHdPnwijr7gasdzUG2IxgdB4bgvgsOdlQ== X-Google-Smtp-Source: ABhQp+TbtaV5gZxFJCDJz/QdibQSq89rp67EMu4Uc4JjTvKhwGHmOJR8k5BmmzThWc2TK+LfQljBjeIe+3V8DvAVRRI= X-Received: by 10.223.157.40 with SMTP id k40mr322683wre.153.1509108331592; Fri, 27 Oct 2017 05:45:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.155.6 with HTTP; Fri, 27 Oct 2017 05:44:51 -0700 (PDT) In-Reply-To: References: From: Igor Mozolevsky Date: Fri, 27 Oct 2017 13:44:51 +0100 Message-ID: Subject: Re: Crypto overhaul To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , freebsd security , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 12:45:33 -0000 Eric, Have a look at mbedTLS which is now part of ARM: https://tls.mbed.org -- Igor M. From owner-freebsd-security@freebsd.org Fri Oct 27 13:46:27 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D695E45796 for ; Fri, 27 Oct 2017 13:46:27 +0000 (UTC) (envelope-from jh-fbml@snkmail.com) Received: from sneak2.sneakemail.com (sneak2.sneakemail.com [64.46.156.55]) by mx1.freebsd.org (Postfix) with ESMTP id 4A91265DB1 for ; Fri, 27 Oct 2017 13:46:27 +0000 (UTC) (envelope-from jh-fbml@snkmail.com) Received: from 206.168.13.214 by sneak2.sneakemail.com with SMTP; 27 Oct 2017 13:46:18 -0000 Received: (sneakemail censored 4207-1509111977-98568 #2); 27 Oct 2017 13:46:18 -0000 Received: (sneakemail censored 4207-1509111977-98568 #1); 27 Oct 2017 13:46:18 -0000 Message-ID: <4207-1509111977-98568@sneakemail.com> Date: Fri, 27 Oct 2017 07:46:07 -0600 From: "John Hein" To: freebsd-security@freebsd.org To: "Eric McCorkle" , , freebsd-security@freebsd.org, MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: References: Subject: Re: Crypto overhaul X-Mailer: Perl5 Mail::Internet v X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 13:46:27 -0000 Eric McCorkle wrote at 20:29 -0400 on Oct 26, 2017: > I was going to wait a bit to discuss this, but it's very pertinent to > the trust infrastructure I described earlier this week. > > There was a good bit of discussion at vBSDCon about a possible crypto > overhaul. This is my understanding of the current situation: > > * Userland crypto support is provided by OpenSSL, of course. My sense > is that there's a general dissatisfaction with OpenSSL, but that there's > a nontrivial effort required to liberate userland from it. > > * The kernel has sort of two crypto APIs: crypto and opencrypto. The > design of these APIs seems to be something of older hardware crypto > architectures and export restrictions. This is difficult to extract > from the kernel (and say, embed into the boot loader). > > * BIOS geli pulled the AES implementation out of opencrypto. This was > due in a large part to the size restrictions on BIOS loaders. > > * As a bridge measure, I've introduced boot_crypto into the EFI loader, > in order to support GELI. > > At vBSDcon, there seemed to be a consensus that this situation is too > fragmented. Moreover, it makes life difficult for anyone (like me) who > wants to do crypto-related projects. > > > A couple of options were discussed at vBSDcon. The two that seemed to > come to the forefront were BearSSL and LibreSSL. There seem to be some > advantages and disadvantages both ways: > > * LibreSSL is mature software with staff and support from another BSD > (OpenBSD), they've done some really good work, and have a definite > long-term roadmap. I'm not sure to what extent it could be easily > embedded into a kernel and bootloader, though. > > * BearSSL's design seemingly lends itself to acting as a userland, > kernel, and bootloader library. On the other hand, it's new (which > means it will need to be reviewed by crypto experts and thoroughly > tested), and has one developer at this point. > > > I think it's worth discussing and investigating these options further at > this point. What's the overhaul goal here? There's basic crypto libraries with symmetric & assymmetric crypto & hashing (e.g., NaCL, libsodium, openssl's libcrypto). There's libraries that add support for SSL/TLS & X.509 certificates and such. There's stuff to support using crypto hardware (accelerators, secure crypto token storage devices). And is the thought to [eventually] replace openssl in base with something lighter perhaps? I assume we're looking for bsd, isc, mit, etc., style licenses only. From owner-freebsd-security@freebsd.org Fri Oct 27 19:24:39 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F3C3E4EF34; Fri, 27 Oct 2017 19:24:39 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5665E74470; Fri, 27 Oct 2017 19:24:39 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 3430C2736D; Fri, 27 Oct 2017 19:24:32 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v9RJOU4K013960; Fri, 27 Oct 2017 19:24:30 GMT (envelope-from phk@phk.freebsd.dk) To: Ben Laurie cc: Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: Crypto overhaul In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13958.1509132270.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Oct 2017 19:24:30 +0000 Message-ID: <13959.1509132270@critter.freebsd.dk> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 19:24:39 -0000 -------- In message , Ben Laurie writes: >OpenSSL includes (and is used for) lots of crypto that is not used in >SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be >used to replace all uses of OpenSSL. Which implicitly raises the question if we really need all the boatloads of crap OpenSSL drags in, or if we would be in a better position with something simpler and saner ? -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-security@freebsd.org Fri Oct 27 20:20:15 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6AA3AE4FEC5; Fri, 27 Oct 2017 20:20:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (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 22C6A75D27; Fri, 27 Oct 2017 20:20:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: by mail-qt0-x241.google.com with SMTP id v41so9863441qtv.12; Fri, 27 Oct 2017 13:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hob5zPYqqke99nQrl/pKzkrDvJ/oVODIqCXCzeeLOMc=; b=mTvYrn/UTWC+1BBcZ9iuqBLZAqy0K83cqYMIjHz74r1YbXOb6eZaNZoHNabquiBixp 7fqk0rWFdjbZR6HReQ5JPuo30oC1u2Ya5yNyQnH4tlUr/nmUoNihwgS0DUbbHRkR6rEd uCL/MNrfJQP/JtxWYdWmYF5A2Lhn/xnOYYHQhbWxx4KamibrSjHohAcf2URHs/MZrNoD v2LtucNwVqkvkPHa79DLqFsjsuTQf6ym2S7aZcdZ0N0Hq2ihEjuk9VeoE/hY0L3Fp/k6 g/JWPmPo5GQKB0fI+A64rY/W/Z5MeaAIWAekF3bpzbxsat7UAZdKEAr11oHp/PzCYOUI Iz+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hob5zPYqqke99nQrl/pKzkrDvJ/oVODIqCXCzeeLOMc=; b=RhPee9ZU4c54WHsYuCkpYeL/g9NmQfiQNaeo3XmD6crS0tG8E0DfDTstPaAvd2tUL2 3Gs5wfePxP3aByCwuQ6UsXJi3g+8YqL2s5ROyD1DDRfwXVAxmTjlaaWyXR8046u7vf5A OdcPc5StdCpbVZDDXVYB9bd1xIcCwB8pgzpQR6ChDS8w8AEr/DUbKK091im1wkAmG/+4 H4VYxAeLMN+YRbp6TYG5D5g3t2yNzaRv+IjD4U3ch6Yf0suhhpnKIHHMcIiphbZM4bBI mL873XSUnplk6+048dPkpEAmlaKDCnmdySDm1PtoR0RBVpMQXR04KpVb8hh3SpIHKF9k jkyw== X-Gm-Message-State: AMCzsaUD6875NBs3mNGKfZld5tJd7lD/+JWpyhuaAzm+1I87hNtnTjNo P0ddOfYZlHUxsz3JK5535GGuhYO7jHx7d1H4yP4dyQ== X-Google-Smtp-Source: ABhQp+QQc1awj77CB0MLCSrOltmcvmAmTqY2Ht1FmokSegFjSZOKR4CVsIw1YR1OuoMNxChR3YXggD/PDzG/EShiOq8= X-Received: by 10.200.43.78 with SMTP id 14mr2903815qtv.72.1509135614261; Fri, 27 Oct 2017 13:20:14 -0700 (PDT) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.200.22.174 with HTTP; Fri, 27 Oct 2017 13:20:13 -0700 (PDT) In-Reply-To: <13959.1509132270@critter.freebsd.dk> References: <13959.1509132270@critter.freebsd.dk> From: Ben Laurie Date: Fri, 27 Oct 2017 21:20:13 +0100 X-Google-Sender-Auth: ibYg2bI62ET_--wyIEY3HLGQGmM Message-ID: Subject: Re: Crypto overhaul To: Poul-Henning Kamp Cc: Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Fri, 27 Oct 2017 20:49:06 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 20:20:15 -0000 On 27 October 2017 at 20:24, Poul-Henning Kamp wrote: > -------- > In message > , Ben Laurie writes: > >>OpenSSL includes (and is used for) lots of crypto that is not used in >>SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be >>used to replace all uses of OpenSSL. > > Which implicitly raises the question if we really need all the > boatloads of crap OpenSSL drags in, or if we would be in a better > position with something simpler and saner ? Indeed it does. Perhaps worth noting that since it was staffed, OpenSSL has removed a fair amount of crap, BTW. Anyway, to answer that question will presumably require someone to either try it, or figure out what is actually needed, crypto-wise. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@freebsd.org Fri Oct 27 23:17:36 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25E12E52F56 for ; Fri, 27 Oct 2017 23:17:36 +0000 (UTC) (envelope-from repeatable_compression@yahoo.com) Received: from sonic305-22.consmr.mail.ne1.yahoo.com (sonic305-22.consmr.mail.ne1.yahoo.com [66.163.185.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB5657E8CE for ; Fri, 27 Oct 2017 23:17:35 +0000 (UTC) (envelope-from repeatable_compression@yahoo.com) X-YMail-OSG: Kl4dQdgVM1msqR.S2NsQ1taP5P51i2wZW7RMAcXBPAbJRFtvDX8Ndjd1Nv77oE4 5y2UaQyl_ojPiQaOgxNTk5whxgtjQTnym6y7IzZRljEbRloGPHuTt8zLqxO5i0DUljwTCUrEnYEF LuS8rxVY9rFX0.IWB2Nx_2ET4dNKw5ctMJt43bQycjj178tPmce7yzcHwcMAHzy_COeZYw61_EGD pWhfSVBZ7rymo1o4_tEIucjbEA0Tn7KKOvr4ONE6y42hNtpy5k.ZIXyelcscJgqYCU56GZGpaFtL OrPASmrcbFmR2jQetXxh.SmWvHaBsGSsBa7vk.bfKLeXj.IWSJpzwZWk1kBSR68NAihCXEGd_9Gp emn1mLkfG915CsRlhE6C5.EuDGQ8RStz900vRJO_gGJJ2Cir1fbiWR90.x6zHKoMPea7rObcF4A9 HTS29xtOkDFIJTkJepvRo7DgVAra2eF0wJH0Uui8DNz7_BcRdvH5rf.hu7qQ7NKe7soHgCtVNvNY rqizFhICacx_uGiokzIpZoTmeFYtfZa3.wzcIbPBY73DTJQKGObcz8lub82Y- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Fri, 27 Oct 2017 23:17:29 +0000 Received: from [127.0.0.1] by smtp111.mail.ne1.yahoo.com with NNFMP; 27 Oct 2017 23:17:24 -0000 X-Yahoo-Newman-Id: 704549.63519.bm@smtp111.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Kl4dQdgVM1msqR.S2NsQ1taP5P51i2wZW7RMAcXBPAbJRFt vDX8Ndjd1Nv77oE45y2UaQyl_ojPiQaOgxNTk5whxgtjQTnym6y7IzZRljEb RloGPHuTt8zLqxO5i0DUljwTCUrEnYEFLuS8rxVY9rFX0.IWB2Nx_2ET4dNK w5ctMJt43bQycjj178tPmce7yzcHwcMAHzy_COeZYw61_EGDpWhfSVBZ7rym o1o4_tEIucjbEA0Tn7KKOvr4ONE6y42hNtpy5k.ZIXyelcscJgqYCU56GZGp aFtLOrPASmrcbFmR2jQetXxh.SmWvHaBsGSsBa7vk.bfKLeXj.IWSJpzwZWk 1kBSR68NAihCXEGd_9Gpemn1mLkfG915CsRlhE6C5.EuDGQ8RStz900vRJO_ gGJJ2Cir1fbiWR90.x6zHKoMPea7rObcF4A9HTS29xtOkDFIJTkJepvRo7Dg VAra2eF0wJH0Uui8DNz7_BcRdvH5rf.hu7qQ7NKe7soHgCtVNvNYrqizFhIC acx_uGiokzIpZoTmeFYtfZa3.wzcIbPBY73DTJQKGObcz8lub82Y- X-Yahoo-SMTP: KDkTLsqswBBCmUTAOzBaZ_hLyVQzFsoqgrhYGNK2rJDiXlA- Subject: Re: Crypto overhaul To: Poul-Henning Kamp , Eric McCorkle , Nathan Whitehorn , "freebsd-security@freebsd.org security" , Ben Laurie , pg@eth1.com, Jeremiasfeliz References: <13959.1509132270@critter.freebsd.dk> From: Jules Gilbert Message-ID: Date: Fri, 27 Oct 2017 19:17:23 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <13959.1509132270@critter.freebsd.dk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 23:17:36 -0000 These days no one talks about how wonderful CPM was, we used it because at one time, it was the only OS available. So what is our excuse for using SSL?, because I'm fairly certain the NSA and just about everyone else in the neighborhood has hacked it. Question for the group...  Does anyone believe that factoring is actually hard.  It was once, I know.  But today? I'm not a crypto person, but even I wrote a simple factoring program.  In C, using MAPM.  I produce a few of the left-most bits for a,b, where: c = a*b; where a is:  3 .. sqrt(c) and (of course,) b must be: greater than sqrt(c) from this I bisect the space of 3 .. sqrt(c) and begin the recursive descent.  The program does about 5,000 prime pairs an hour and this using MAPM!! I gave away the source code, let me know if you didn't get a copy.  You'll need g++ and MAPM On 10/27/2017 3:24 PM, Poul-Henning Kamp wrote: > --------IQjeDjYnGtJpS9Q@mail.gmail.com> > , Ben Laurie writes: > >> OpenSSL includes (and is used for) lots of crypto that is not used in >> SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be >> used to replace all uses of OpenSSL. > Which implicitly raises the question if we really need all the > boatloads of crap OpenSSL drags in, or if we would be in a better > position with something simpler and saner ? > From owner-freebsd-security@freebsd.org Sat Oct 28 02:26:17 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83E20E585EF; Sat, 28 Oct 2017 02:26:17 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 026B98456F; Sat, 28 Oct 2017 02:26:16 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190e-651ff70000007a39-ef-59f3eac0500f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 1B.04.31289.0CAE3F95; Fri, 27 Oct 2017 22:26:09 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v9S2Q3wl031486; Fri, 27 Oct 2017 22:26:05 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9S2PvpY019877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Oct 2017 22:25:59 -0400 Date: Fri, 27 Oct 2017 21:25:57 -0500 From: Benjamin Kaduk To: Ben Laurie Cc: Poul-Henning Kamp , Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: Crypto overhaul Message-ID: <20171028022557.GE96685@kduck.kaduk.org> References: <13959.1509132270@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUixG6nonvw1edIg0XX+S0Wzea0+Db9L4vF 7OnTmCy2b/7HaNGz6QmbxYdv/A5sHjM+zWfx2Nw0h83j3o4JTB6f9k9mC2CJ4rJJSc3JLEst 0rdL4Mq423GQreCzcMWJny/ZGxibBboYOTkkBEwkTk9Yy9TFyMUhJLCYSeLwtMWsEM5GRok5 r99AOVeZJJovH2ICaWERUJX4230UzGYTUJN4vLeZFcQWEZCT+H37CwtIA7PABiaJp4uugRUJ C8hIHDx7CczmBdp38dtbFoipPxglHuw/zAyREJQ4OfMJC4jNLKAlcePfS6AGDiBbWmL5Pw6Q MKdAoMTyTyvBlokKKEvM27eKbQKjwCwk3bOQdM9C6F7AyLyKUTYlt0o3NzEzpzg1Wbc4OTEv L7VI11gvN7NELzWldBMjKMQ5Jfl2ME5q8D7EKMDBqMTDK5H7OVKINbGsuDL3EKMkB5OSKO++ 858ihfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwXsgHKudNSaysSi3Kh0lJc7AoifNuC9oVKSSQ nliSmp2aWpBaBJOV4eBQkuA99xKoUbAoNT21Ii0zpwQhzcTBCTKcB2j4c5Aa3uKCxNzizHSI /ClGS45NN+/+YeLY8P0BkHw283UDsxBLXn5eqpQ47weQBgGQhozSPLiZoJQlkb2/5hWjONCL wrzCwAQmxANMd3BTXwEtZAJa2KT6AWRhSSJCSqqB8VjLFD9boZ7dM0W8cnjqRbse1BbEHlHN L163r+6yMltgdFiTbMW2RMmM2P/e92d2ZXz781tlm3Xw5ivij2ysThh01+5ZYmr7Lv2Cbuiu TQn35+wIDFee9UCoRPT4X6++ZdrvuRj/TvH56cE3va1PTOKtttnUP4+/KJ4UDdu4htElMMow 9U+QEktxRqKhFnNRcSIAIRI7gTQDAAA= X-Mailman-Approved-At: Sat, 28 Oct 2017 03:08:14 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 02:26:17 -0000 On Fri, Oct 27, 2017 at 09:20:13PM +0100, Ben Laurie wrote: > On 27 October 2017 at 20:24, Poul-Henning Kamp wrote: > > -------- > > In message > > , Ben Laurie writes: > > > >>OpenSSL includes (and is used for) lots of crypto that is not used in > >>SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be > >>used to replace all uses of OpenSSL. > > > > Which implicitly raises the question if we really need all the > > boatloads of crap OpenSSL drags in, or if we would be in a better > > position with something simpler and saner ? > > Indeed it does. Perhaps worth noting that since it was staffed, > OpenSSL has removed a fair amount of crap, BTW. Full disclosure: I am an OpenSSL committer (but not a member of the management committee). It is true that a lot of crap has been removed recently, and the test suite has gotten more robust (not the least due to the addition of a large portion of the BoringSSL test suite). But we're still constrained by a heavy burden of API/ABI stability in major release branches (compounded by a promise to make the next release branch 1.1.1, with TLS 1.3 support, so ABI-breaking changes are currently on indefinite hold). That, combined with an existing public API that grew quite organically and without a great deal of thought, still makes for a system that is hard to maintain well. But I think the main issue with OpenSSL in base that was leading to thoughts about replacing it is the mismatch between FreeBSD release branch support lifecycles and OpenSSL release branch support lifecycles. That is, we (FreeBSD) would be stuck supporting an OpenSSL version that is EOL upstream, which is not a great position to be in. On the other hand, upstream OpenSSL is taking ABI compatibility more seriously, so it might be reasonable to (e.g.) upgrade from 1.1.0 to 1.1.1 within a FreeBSD stable branch than it would (not) have been to upgrade from 1.0.1 to 1.0.2. That might make the support lifecycle concerns go away. > Anyway, to answer that question will presumably require someone to > either try it, or figure out what is actually needed, crypto-wise. Indeed, and I do not think I can volunteer. -Ben P.S., when Chris H mentioned "an alternative with a long history of reliability, safety, and a great deal of scrutiny by seasoned developers, and security engineers", I couldn't really tell what that alternative was supposed to be. From owner-freebsd-security@freebsd.org Sat Oct 28 08:03:38 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAC5EE5E67A; Sat, 28 Oct 2017 08:03:38 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7977D6723E; Sat, 28 Oct 2017 08:03:38 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9503027374; Sat, 28 Oct 2017 08:03:35 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v9S83Wap023377; Sat, 28 Oct 2017 08:03:34 GMT (envelope-from phk@phk.freebsd.dk) To: Benjamin Kaduk cc: Ben Laurie , Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: Crypto overhaul In-reply-to: <20171028022557.GE96685@kduck.kaduk.org> From: "Poul-Henning Kamp" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23375.1509177812.1@critter.freebsd.dk> Date: Sat, 28 Oct 2017 08:03:32 +0000 Message-ID: <23376.1509177812@critter.freebsd.dk> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 08:03:38 -0000 -------- In message <20171028022557.GE96685@kduck.kaduk.org>, Benjamin Kaduk writes: >But I think the main issue with OpenSSL in base that was leading to >thoughts about replacing it is the mismatch between FreeBSD release >branch support lifecycles and OpenSSL release branch support lifecycles. That's not why I want OpenSSL gone from the tree. My reason is that I think OpenSSLs architecture, (to the extent you can talk about OpenSSL having one), APIs and the source code are all horrible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@freebsd.org Sat Oct 28 08:17:52 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32188E5ED4F; Sat, 28 Oct 2017 08:17:52 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D26167A53; Sat, 28 Oct 2017 08:17:51 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id v9S8Hodv018008 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 28 Oct 2017 01:17:50 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id v9S8Hogh018007; Sat, 28 Oct 2017 01:17:50 -0700 (PDT) (envelope-from jmg) Date: Sat, 28 Oct 2017 01:17:50 -0700 From: John-Mark Gurney To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" Subject: Re: Crypto overhaul Message-ID: <20171028081750.GG42467@funkthat.com> Mail-Followup-To: Eric McCorkle , "freebsd-arch@freebsd.org" , freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 28 Oct 2017 01:17:50 -0700 (PDT) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 08:17:52 -0000 Eric McCorkle wrote this message on Thu, Oct 26, 2017 at 20:29 -0400: > I was going to wait a bit to discuss this, but it's very pertinent to > the trust infrastructure I described earlier this week. > > There was a good bit of discussion at vBSDCon about a possible crypto > overhaul. This is my understanding of the current situation: > > * Userland crypto support is provided by OpenSSL, of course. My sense > is that there's a general dissatisfaction with OpenSSL, but that there's > a nontrivial effort required to liberate userland from it. > > * The kernel has sort of two crypto APIs: crypto and opencrypto. The > design of these APIs seems to be something of older hardware crypto > architectures and export restrictions. This is difficult to extract > from the kernel (and say, embed into the boot loader). I wouldn't call them crypto and opencrypto.. There is the opencrypto API, as documented by crypto(9), and then there are various undocumented API's in sys/crypto that give direct software access to various hash and cipher functions... > * BIOS geli pulled the AES implementation out of opencrypto. This was > due in a large part to the size restrictions on BIOS loaders. > > * As a bridge measure, I've introduced boot_crypto into the EFI loader, > in order to support GELI. > > At vBSDcon, there seemed to be a consensus that this situation is too > fragmented. Moreover, it makes life difficult for anyone (like me) who > wants to do crypto-related projects. The opencrypto API is a very terrible API. There are lots of issues w/ it, and it should be overhauled. The algorithm agility that it provides is more complex than needed, and very few people need the options it provides. It increases driver complexity to support the many different ways that encryption and mac algorithms can be ordered... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@freebsd.org Sat Oct 28 13:16:03 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7118FE43448; Sat, 28 Oct 2017 13:16:03 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4196F30E; Sat, 28 Oct 2017 13:16:02 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5543C27342; Sat, 28 Oct 2017 13:16:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v9SDFxJF024229; Sat, 28 Oct 2017 13:15:59 GMT (envelope-from phk@phk.freebsd.dk) To: Benjamin Kaduk cc: Ben Laurie , Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: Crypto overhaul In-reply-to: <20171028123132.GF96685@kduck.kaduk.org> From: "Poul-Henning Kamp" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24227.1509196559.1@critter.freebsd.dk> Date: Sat, 28 Oct 2017 13:15:59 +0000 Message-ID: <24228.1509196559@critter.freebsd.dk> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 13:16:03 -0000 -------- In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk writes: >I would say that the 1.1.x series is less bad, especially on the last count, >but don't know how much you've looked at the differences in the new branch. While "less bad" is certainly a laudable goal for OpenSSL, I hope FreeBSD has higher ambitions. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@freebsd.org Sat Oct 28 12:36:57 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 282C1E425B0; Sat, 28 Oct 2017 12:36:57 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61F0C6E43C; Sat, 28 Oct 2017 12:36:55 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074422-b6dff7000000159a-82-59f478ad6dd6 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 22.44.05530.EA874F95; Sat, 28 Oct 2017 08:31:43 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v9SCVbZ3006042; Sat, 28 Oct 2017 08:31:38 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9SCVWaM031555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 28 Oct 2017 08:31:35 -0400 Date: Sat, 28 Oct 2017 07:31:32 -0500 From: Benjamin Kaduk To: Poul-Henning Kamp Cc: Ben Laurie , Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: Crypto overhaul Message-ID: <20171028123132.GF96685@kduck.kaduk.org> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23376.1509177812@critter.freebsd.dk> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUixG6nrru+4kukwYsnKhaLZnNafJv+l8Vi 9vRpTBbbN/9jtOjZ9ITN4sM3fgc2jxmf5rN4bG6aw+Zxb8cEJo9P+yezBbBEcdmkpOZklqUW 6dslcGVsWb2KseAMd8W/+/cZGxhXcHYxcnJICJhI7HrTx9jFyMUhJLCYSeL4ngYoZyOjxJG7 i9khnKtMEnv6DrKCtLAIqEqcvXOcEcRmE1CTeLy3GSwuIqAlsXb2WSaQBmaB2UwSq4+1gBUJ C8hIHDx7iQnE5gXaN+3FDmaIqaeZJD433mOESAhKnJz5hAXEZgaadOPfS6AGDiBbWmL5Pw6Q MKeAkcS2prNgy0QFlCXm7VvFNoFRYBaS7llIumchdC9gZF7FKJuSW6Wbm5iZU5yarFucnJiX l1qka6qXm1mil5pSuokRHOIuSjsYJ/7zOsQowMGoxMMrkfs5Uog1say4MvcQoyQHk5Io777z nyKF+JLyUyozEosz4otKc1KLDzFKcDArifAGlX+JFOJNSaysSi3Kh0lJc7AoifNuC9oVKSSQ nliSmp2aWpBaBJOV4eBQkuBdC9IoWJSanlqRlplTgpBm4uAEGc4DNPw02PDigsTc4sx0iPwp RkuOTTfv/mHi2PD9AZB8NvN1A7MQS15+XqqUOK8WSIMASENGaR7cTFDKksjeX/OKURzoRWHe RpAqHmC6g5v6CmghE9BCDUmwhSWJCCmpBkYOx6rmdXYcj5lerOv/uaev2n/Lpo08oU1xgf8v ntrGNVX31/I9Ebl/Q91UfGXUl9j/+P3P9ODTwHl/vNWurT7JYiIeb7ipXzSPcSZ/WcPvhzcY Ju7utrj6peyGWuONUxyXZRMX2yXmir7MqMqM5ul6JfzJ9qHStZnrr17bNn+S/Hzh+++X5vxV YinOSDTUYi4qTgQA0N6zLDQDAAA= X-Mailman-Approved-At: Sat, 28 Oct 2017 13:17:08 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 12:36:57 -0000 On Sat, Oct 28, 2017 at 08:03:32AM +0000, Poul-Henning Kamp wrote: > -------- > In message <20171028022557.GE96685@kduck.kaduk.org>, Benjamin Kaduk writes: > > >But I think the main issue with OpenSSL in base that was leading to > >thoughts about replacing it is the mismatch between FreeBSD release > >branch support lifecycles and OpenSSL release branch support lifecycles. > > That's not why I want OpenSSL gone from the tree. > > My reason is that I think OpenSSLs architecture, (to the extent you > can talk about OpenSSL having one), APIs and the source code are > all horrible. Those are all fine reasons for an individual to want OpenSSL gone from the tree, and I can't really dispute any of them for the 1.0.x series. I would say that the 1.1.x series is less bad, especially on the last count, but don't know how much you've looked at the differences in the new branch. Regardless, the point I was intending to make is that, fine reasons those are, they in and of themselves may not be enough to overcome the weight of POLA for staying with OpenSSL. I do, however, remember a few years ago a Security Officer raising concerns about the support lifecycle mismatch, and in that context that reason does seem to be able to overcome the weight of POLA. That is, I was talking about history. We should of course make our own, fresh, decision about whether your reasons are currently enough to outweigh POLA, for the present discussion. -Ben From owner-freebsd-security@freebsd.org Sat Oct 28 21:52:07 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71850E4E35C for ; Sat, 28 Oct 2017 21:52:07 +0000 (UTC) (envelope-from rms@gnu.org) Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:4830:134:3::10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46F3381833 for ; Sat, 28 Oct 2017 21:52:07 +0000 (UTC) (envelope-from rms@gnu.org) Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e8Z1R-0006ir-KP for freebsd-security@freebsd.org; Sat, 28 Oct 2017 17:52:06 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e8Z1E-0006ML-7k; Sat, 28 Oct 2017 17:51:52 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1e8Z1D-0002Pw-EV; Sat, 28 Oct 2017 17:51:51 -0400 From: Richard Stallman To: Jules Gilbert CC: phk@phk.freebsd.dk, eric@metricspace.net, nwhitehorn@freebsd.org, freebsd-security@freebsd.org, ben@links.org, pg@eth1.com, jeremiasfeliz@hotmail.com In-reply-to: (message from Jules Gilbert on Fri, 27 Oct 2017 19:17:23 -0400) Subject: Re: Crypto overhaul Reply-to: rms@gnu.org References: <13959.1509132270@critter.freebsd.dk> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-Id: Date: Sat, 28 Oct 2017 17:51:51 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Mailman-Approved-At: Sat, 28 Oct 2017 22:47:05 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 21:52:07 -0000 [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I'm not a crypto person, but even I wrote a simple factoring program.  > In C, using MAPM.  I produce a few of the left-most bits for a,b, where: > c = a*b; > where a is:  3 .. sqrt(c) > and (of course,) b must be: greater than sqrt(c) If defeating RSA were this easy, the experts would know it and nobody would recommend using RSA. This includes the experts that I consult, that want to help GNU. I conclude you must have made a mistake somewhere. -- Dr Richard Stallman President, Free Software Foundation (gnu.org, fsf.org) Internet Hall-of-Famer (internethalloffame.org) Skype: No way! See stallman.org/skype.html. From owner-freebsd-security@freebsd.org Sat Oct 28 23:31:07 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FE22E50747; Sat, 28 Oct 2017 23:31:07 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 3B66D83D9B; Sat, 28 Oct 2017 23:31:07 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 9489D174B; Sat, 28 Oct 2017 23:31:06 +0000 (UTC) Subject: Re: Crypto overhaul To: John Hein , freebsd-arch@freebsd.org, freebsd-security@freebsd.org, freebsd-hackers@FreeBSD.org References: <4207-1509111977-98568@sneakemail.com> From: Eric McCorkle Message-ID: Date: Sat, 28 Oct 2017 19:31:06 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <4207-1509111977-98568@sneakemail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 23:31:07 -0000 On 10/27/2017 09:46, John Hein wrote: > What's the overhaul goal here? There's basic crypto libraries with > symmetric & assymmetric crypto & hashing (e.g., NaCL, libsodium, > openssl's libcrypto). There's libraries that add support for SSL/TLS > & X.509 certificates and such. There's stuff to support using > crypto hardware (accelerators, secure crypto token storage devices). > > And is the thought to [eventually] replace openssl in base with > something lighter perhaps? > > I assume we're looking for bsd, isc, mit, etc., style licenses only. > Sorry for being slow to reply. There's a couple of goals that seem to be in common here (and which I've seen reflected in the comments to my original posting. * Dissatisfaction with the OpenSSL codebase and its history of vulnerabilities. * Desire to consolidate the crypto implementations, specifically, for a crypto library that can serve userland, kernel, and bootloaders. * In my case, the trust framework stuff I wrote about requires public-key crypto in the kernel and loader, which isn't something the kernel crypto framework can do. * It's also harder to add new ciphers when there's multiple crypto codebases.