Minutes from IEEE
P1619 meeting, Thursday Feb. 26 2004.
Meeting Location:
Milpitas, CA. Some attendees used phone linkup.
Minutes were taken
by Jim Hughes and Clement Kent
Present:
Jim Hughes, STK (JH)
Shai Halevi, IBM (SH)
Bob Nixon, Emulex (BN)
Steve Sletten, Sun (SS)
Clement
Kent, Kasten Chase (CK)
Serge Plotkin, Decru (SP)
Fabio Maino, Andiamo/Cisco (FM)
Dalit Naor, IBM (on Phone) (DN)
Kumar from
Neoscale (on phone) (K)
Jim Williams, Emulex (on phone) (JW)
-------------------------------------------------------
The IEEE Patent
presentation was read. No questions were raised.
Minutes from the
previous meeting were read. Motion to accept minutes made by Jim Hughes,
seconded by Fabio Maino, approved by acclamation.
Jim reminded the
group of voting and membership rules as follows:
- Membership is open to anyone
after attending 2 consecutive meetings in the last year,
including the current meeting. For the purpose of counting the two meetings, a
company is considered in attendance
if either its primary or secondary
representative is participating in the meeting,
either in person or by phone. Jim is keeping a
spreadsheet of attendance to establish who current voting members
are.
Voting -
- quorum of votes cast.
- Electronic votes are permitted, reduced to paper,
and a full quorum must participate. Quorum is
>50% of voting members. One vote per company.
- Straw polls are informal. All in
attendance.
-------------------------------------------------------
Action
Items:
Actions
brought forward from last meeting:
-
overview document reassigned from JH to
CK
- Wide block - SH - closed
-
sample code for wide block - SH - open
-
r=1 reassigned to CK, under
revision
- key backup - closed
- OSD encryption still open.
New actions:
- JH -
post past minutes to web
- SH -
bring forward intro& motivations section, to
be copied into other documents
- Next
Meeting date: Friday April 16 10-5, in
College Park Maryland to accompany the NASA/IEEE mass storage conference (see http://storageconference.org/2004/).
This info to be published on http://www.siswg.org/ by
JH
- a number of
other in-progress document editing steps or reports to other groups are
described in the detailed minutes below.
-------------------------------------------------------
Discussion:
EME
document:
This was presented
by SH. Document is on reflector.
Note that a number of the comments were agreed to apply to all
other documents, so same changes should be made to them.
- change to address
usage only for storage, not a general algorithm. Use phrase "data at rest
encryption"
- storage to cover object store - not be too
specific
- specify the tweak as the serial number of the blob. "Blob" is our current working name for the unit of
storage encryption, previously called "sector". We are still looking for a name
which has implications of a fixed length storage object, rather than the general
variable length objects understood by database people to be "blobs". SS liked
"glob". SH suggests "wide block" (or
wblock for short).
- add something to the document about the bad idea of using the
same key and same tweak in more than one location
- For
tape, objects (in the sense of OSD) or 520 byte or other sector (aka
blob) sizes it is expected that these are out of scope for this
document.
-
CK raised question of adding padding words for ragged chunks of data -
agreed to defer this to possible other document, and Dalit and Julian Satran may address it
for
ObjectStorage.
-
Question raised regarding tape vs disk.
Suggested may have separate recommendation for
encryption modes for tape involving extra integrity bytes. JH says lets
avoid SHA for these, in favor of simplicity of
methods using AES such as AES-hash (or Whirlpool???)
- Shai asked to limit EME-32-AES scope to
512 byte strings.
- T10
is doing 16 bit CRC. SCSI can do 520 bytes. See T10 SBC-2
(http://www.t10.org/ftp/t10/document.03/03-176r0.pdf) 8 bytes from
512 up are 2 bytes
CRC, 2 bytes app tag, 4 bytes block number. Can't be
re-used for tape
integrity.
-
Shai's doc doesn't specify tweak, other doc requ'd for tweak spec.
Discussion of correct place to put
tweak. Serge suggests putting tweak generation procedures
in Shai's document
along with identifiers for these.
Key Backup
document:
This was presented
by DN.
- "key escrow" and
"key recovery" were rejected in favor of "key backup"
- much discussion of
meaning of fields - details not all recorded here. DN will issue revised draft
with changes as discussed. One main thread in discussion was to have unique
identifiers for cipher modes which include version numbers. A cipher mode
identifier will uniquely identify key strength (128, 256, etc), r mode (EME-32,
LRW-1), and tweak method. SP emphasized need to easily separate out version
numbers.
- noted that
ultimate key backup representation will be XML, therefore field sizes in this
document refer to upper limits of length of values, not actual representation
lengths in XML
-
Discussed that LBA_START overloads two meanings: where the data encoded
by this algorithm starts, and what origin value the tweak function begins
with. SP mentioned some reasons why the
separation of meaning is important.
- SP
mentions possible need for a field identifying the storage to which the key
applies. Much discussion. Agreement for
now to use "COMMENT" field if desired for this.
-
Discussion re need to standardize XML standard used. CK will send email
to Dalit cc all pointing to a specific
IETF standard. He will propose specific methods and
wrap/unwrapped
options.
- CK notes that exporting unwrapped keys may
violate vendor product FIPS
certifications, therefore mandating unwrapped
keys in backup could cause problems
LRW-1
document
This was presented
by CK.
- CK
and Cyril Guyot will revise [TWEAK] to acknowledge the committee, details of
names to be added later.
-
Change codes in document references to
form TWEAK03, LRW02, etc (suffix year).
-
Change sector to blob, key recovery to key
backup.
-
Sponsor shd be IEEE Standards rather than SISWG.
- CK:
will revise LRW-AES paper with wording
changes and recirculate before next
meeting.
Scramble:
- Proposer was not present to discuss "Scramble"
paper. He may reintroduce it to a future meeting's
agenda.
Other
items:
- BN
raises question of whether movement of data by snapshot replication equipment which does not
respect logical sector/cipherblock offsets
will make data unreadable due to
tweaking. Answer from several:
yes, by design. Example: Veritas volume mgr will attempt to backup by
sectors in a way that will not be readable.
- CK
raises question of which other groups need to be aware of our status. T10, TCG are suggested. Next TCG face to face is Mar
31, Apr 1-2 San Diego. Weekly con-calls.
Shai will talk to IBM TCG people.
Bob Nixon will offer T10 a presentation. Steve Sletten will inform TCG of what we are doing, and offer the
opportunity for a more detailed follow-up.
-
Encourage e-mail correspondence to
shorten April meeting. Goal: schedule
phone call 2 weeks before April meeting to
resolve items early, with hope of having final drafts approved at April
meeting.