To: T10@t10.org, Paul.Entzel@quantum.com
Subject: 07-061r1: SSC-3 Additional controls for keyless copy
From: Kevin D Butt <kdbutt@us.ibm.com>
Date: Fri, 2 Mar 2007 18:30:57 -0700
X-Message-Number: 7612
Formatted message: HTML-formatted message
Attachment #1: 07-016r1_w_kdbutt_comments.pdf

Paul,
I have some feedback for your 07-061r1 proposal.
First, I want to make sure that it is backward compatible.  There are 
several places where assumptions are made that the encryption mode used 
during the write has not been done by any device in the past.  This is not 
true.  See the pdf with markups for specifics. 
Second, I am uneasy with going down this path of providing application 
clients methods to mess with forcing a format to either record or not 
record an indication.  I think a thorough examination of the merits is in 
order.	I do not say that I will oppose it, as I am currently undecided. I 
do not resist having formats record an indication - they can do what they 
think best.  However, if a vendor decides that he needs to disallow reads 
of a data written in the EXTERNAL mode to achieve some government 
compliance, then the vendor can take appropriate actions.  There is no 
need for a knob here and in fact there is a need to not have a knob here - 
at least from a drive compliance perspective.  On the other hand, a user 
may have requirements to specify that the data he writes be guaranteed to 
not allow keyless copy - at least for the norm (there is no way he can 
truly do this as the drive vendor can always have its methods to get 
around anything in the format).  If the user has this knob, he will be 
tempted to use it in a manner he thinks is best.  That is, the data center 
IT person.  Unless this person is a true security person, the knob 
selection may be chosen in a manner that is unduly prohibitive or not 
prohibit enough.  This part about prohibiting a raw read being bad is a 
raging debate where the true cryptographers are saying it is next to 
worthless - akin to putting a child lock on a drawer.  It inhibits the 
unlearned for a short time, but that's all.  If your encryption algorithm 
is not strong enough to stand encrypted data being available, then it is 
not sufficient.  My intent is these statements is not to debate the merits 
of the child lock, but to debate the necessity to have knobs to allow 
users to mess with that child lock.  I think it creates a lot of protocol 
work in design and testing that provides very little to no value add.  In 
the end, if vendor A decides that in order to get FIPS certification he 
has to not allow raw read of the data, that is what he will do.  And he 
will not allow a knob because it will then make him non compliant.
In summary, just because a format has put in a feature that will allow it 
to disable raw reads in the future, does not mean that T10 should put in 
knobs to mess with that feature.  This should be left to the vendor to 
decide what its format will do.
I have no issue with providing access to the status of which mode was used 
to encrypt.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt@us.ibm.com
http://www-03.ibm.com/servers/storage/