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/