#ident "@(#)issues	1.7 07/07/11 SAC"

PSARC 2007/261: ZFS Encrypted Datasets
Submitter:	Darren Moffat
Owner:		Darren Moffat
Intern:		Garrett D'Amore	

Issues for inception (07/11/2007):

jdc-1	Since ZIO_CRYPT_ON is equal to ZIO_CRYPT_AES_128_CBC, what
	usage does "on" support?  Does "on" mean "most likely usable,"
	or "fastest," or "most secure," or "best for this release," or
	what?

jdc-2	Doesn't IEEE P1619 define other methods for disk encryption
	(XTS-AES)?  What's the relationship between this project and
	the standards process?

jdc-3	What should a user know (if anything) in order to choose an
	encryption mode?  What will the documentation say about CCM
	and CBC?

jdc-4	What operational effect occurs to a ZFS file system when the
	key is deliberately destroyed or regenerated?  Does "zfs
	mountall -a" fail at boot time (and make the system inoperable
	due to filesystem/local not coming on line)?  Does ZFS know
	when to treat a destroyed data set as "empty?"

ged-1	Has the project team considered "plausible deniability"?  Is there
	any meta data on the disks which could be used to distinguish
	the presence of random garbage from encrypted data?

wes-1   Need a clear statement of threat model of phase 1 in materials,
	please.  It's impossible to judge whether you've succeeded in
	adding confidentiality and integrity protection to
	ZFS which is robust in the face of threats to the underlying 
	storage without clearly describing the threats you've considered.

wes-2	nit: requirements as phrased imply zfs encryption will always be
	enabled, which is inconsistent with the rest of the document

wes-3 	section 3.3 (encrypted zvol for swap) appears to be out of synch
	with the plan for zfs swap/dump proposed in 2006/370 (which
	involves a new pseudo-disk device backed by preallocated pool
	space (with no CoW); please synch up with that team soon, and
	ideally before either project comes for commitment review.

wes-4 	Fine details of algorithm usage need to be nailed down early
	(especially details around choice of initialization vectors or
	equivalent) so they can be reviewed by experienced
	cryptographers.  please include these details and information
	about who's reviewed them (and what these reviewers said..) as 
	part of the commitment spec.  (see also my design review comments 
	re: allowing a trusted encryption module to pick all the 
	security-relevent parameters such as the IV).

wes-5	can you briefly describe how you'd recover from a key compromise?

wes-6	can you briefly describe how you'd receover after a key was lost
	unretrievably? 

wes-7   I was expecting to see either a revised version of the ZFS
	on-disk format spec with encryption additions, or an addendum
	to that spec explaining precisely which on-disk structures are
	encrypted and how.

In meeting issues:

gw-1	What is the story around key recovery (key escrow)?

gw-2	How will delayed execution work if $HOME is encrypted,
	the user is logged out, the system reboots?

gw-3	What is the interaction with the user/admin for unwrapping
	the pool keys?  Is it automatic during login?  Is it something
	like /etc/.rootkey? 
	How is trusted path preserved?

ged-2	What is the interaction of encrypted data sets with zpool import
	and export?