07-061r1: SSC-3 Additional controls for keyless copy
Kevin D Butt
kdbutt at us.ibm.com
Fri Mar 2 17:30:57 PST 2007
Formatted message: <A HREF="r0703029_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0703029_07-016r1_w_kdbutt_comments.pdf">07-016r1_w_kdbutt_comments.pdf</A>
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 at us.ibm.com
More information about the T10
mailing list