(P1619 minutes follow the P1619.1 minutes)
P1619.1 Meeting Minutes
==============================
Conference Call held on May 23rd, 2006 from 8-11am PDT
Attendance:
-----------
Gideon Avida, Decru
Matt Ball, Quantum
Jon Buckingham, HP
Rob Elliott, HP
Rob Ewan, Kasten Chase
John Geldman, Lexar
Shai Halevi, IBM
Jim Hughes, Sun
Glen Jaquette, IBM
Curt Kolovson, HP
Fabio Maino, Cisco
Garry McCracken, Kasten Chase
Landon Noll, Neoscale
Jim Norton, Brocade
Serge Plotkin, Stanford
Jim Scott, Vitesse Semiconductor
Bob Snively, Brocade
Greg Unruh, Quantum
Chris Williams, HP
Matt Ball chairing the meeting, Shai Halevi scribing.
* Matt went over the standard IEEE slides (patents/inappropriate topics)
* Minutes from last meeting approved
* Agenda for today approved, first discussing 1619.1, then 1619
Discussion of 1619.1, draft 7:
------------------------------
* Rob Eliott suggests to change the name from "variable length" to
"not length-preserving".
Matt proposes "authenticated encryption", notes that this requires
modification to the PAR document for 1619.1. Action item for Matt and
Jim Hughes to make the appropriate changes to the the PAR document.
* Discussion on the need to change the term 'VB-device' in the document to
something else. Suggested to change it to "cryptographic module" (in
the same sense as it is used in NIST 140-2).
Matt moves to vote on "changing the term VB-device to cryptographic
module and fixing the text accordingly on a case-by-case basis", motion
approved unanimously.
* Comments by Rob Ewan on draft 6: correction made in draft 7 reflect
these comments appropriately.
* Comments by Shai: Should we mandate key-transform?
Matt: Need to check whether this is consistent with NIST certification,
we don't want to mandate something that will prevent getting
certification. Also, using key transform makes raw-read a bit harder.
Jon: The raw-read issue with key transform can be handled in a
reasonable way by the specific formats, no need to address it
specifically in this standard.
Action item for Matt: find out from NIST about certification.
* Explicit specification of IV sequences (in Shai's note): need to add
language to make it clear that a "sequence" can have just a single IV.
* Discussion of limiting FormatSpecific field in key transform to 15
bytes: the reason is that otherwise we may be susceptible to off-line
collision attacks against SHA-256.
The other option would be to use HMAC for key transform instead of raw
SHA-256. No real consensus about which is better.
Action item for Matt (again): try to see which is more likely to allow
NIST certification.
Serge: clarification, why are we using key-transform at all? What is
gained compared to keeping the same key but doing an "IV transform"?
i. The IV is shorter so collisions are more likely
ii. key-transform was originally proposed so that the encryptor will
not have to have source of randomness
Consensus that having key-transform is convenient, we will keep it.
* Discussion: how many "bits of randomness" should we require when the IV
is generated at random? Should we require 96 (pseudo)random bits for a
96-bit IV?
We can leave a few bits out for other purposes, e.g., for specifying
the manufacturer within a given technology. Three bits are sufficient
for that.
Glen: if we have long sequences of IVs then it is reasonable to have
leave more bits out: you can set them to zero initially and increment
them withing the sequence. As long as you have sequences that cover
(close to) the whole range of bits that you leave off, you don't lose
anything in collision probability.
Matt suggested that we drop the word 'pseudo' from pseudo-random so
that continuously random bit generators are also allowed.
* Reserved values for the FormatSpecific field (in Shai's note). Matt
prefers to leave them off.
* Going over the changes between 1619.1 D6 and D7:
* Preventing replay/reorder attacks: Matt's proposal is to include a
sequence number in either the IV or the AAD so the reader can detect
records that are out-of-order.
Jon: This concern can/should be addressed by higher-level applications.
Discussion of putting such sequence numbers in the IV vs. AAD. If
putting in the IV, may need to use IVs that are longer than 96 bits.
(But if using less bits of randomness as per Glen's comment from above
then can use IV for determining order.)
Suggested to put some text about this in an informative section (but
not in a normative part).
* Text in D6/D7 about the differences between a record as seen by the
host and an encrypted record on the media. rewrite so it does not talk
specifically about LTO.
* Test vectors in D7: most are verified but not all:
CCM test vectors 6 and 8 not yet verified (8 may be incorrect?)
GCM test vectors 6 and 9-11 not yet verified.
* Next meeting: tentatively on July 19, 9am-12pm PDT
P1619.1 Action Item Summary
---------------------------
* Matt Ball and Jim Hughes to make the appropriate changes to the PAR document
for changing the name of the P1619.1 standard. (Due June 6th)
* Matt to change 'VB-device' to 'cryptographic module' within the P1619.1
document
* Matt to check with NIST about approved key derivation algorithms
* Matt to remove discussion of LTO from P1619.1 document.
P1619 Meeting Minutes
==============================
Conference Call held on May 23rd, 2006 from 12:00 pm to 2:30 pm PDT
Jim Hughes was the chair for this meeting, and Matt Ball was the scribe.
Additional Attendance:
----------------------
Guido Bertoni, ST Micro
Laszlo Hars, Seagate
Eric Hibbard, Hitachi Data Systems
Dalit Naor, IBM
(See list from P1619.1 minutes for other attendees)
Meeting started at 12:00 pm PDT
Jim Hughes discussed IEEE patent slides
Minutes from last meeting approved
Agenda approved
* The working group will start enrollment process for IEEE 1619 approval
after the draft is back from IEEE editors. Jim Hughes will follow-up
with IEEE to find out their current progress.
* There was some discussion about submitting LRW to NIST as a proposed
encryption
mode. Jim H. said that we need to finalize the IEEE 1619 standard first, then
submit the LRW mode to NIST.
* There was discussion about the applicability of the P1619 title.
Specifically,
there was dislike for the name 'shared' because it can be somewhat ambiguous.
Shai will provide a better definition of 'shared' for the working group.
* Laszlo was not happy with the P1619 draft as it stands, and read a list of
items
that need to be addressed. Laszlo will publish this list to the e-mail
reflector
* Jim Hughes requested that we set-up a Wiki for collaboration. We also
discussed
whether we need to restrict access to P1619 members only. The consensus was
that
the P1619 working group may be open to everyone because P1619 has 'individual'
membership instead of 'entity' (i.e. company) membership. However, official
clarification on the issue would be useful.
* We discussed at length the possibility of creating a new PAR for a possible
P1619.# working group. Many people agreed that this would be useful and that
they would participate. Laszlo will create a PAR proposal.
* Jim Hughes's cell phone died and Matt Ball took over the remainder of the
meeting.
* Next meeting is scheduled for June 7th from 9:00 a.m. to 12:00 p.m., PDT.
Laszlo
will look into setting up a WebEx conference through Seagate.
* Meeting adjourned at 2:30 PDT
Action Items for P1619
----------------------
* Jim Hughes to follow up with IEEE and get an estimate on the editing progress
(Due June 6th)
* Laszlo to publish a list of requested changes to P1619 (Due May 24th)
* Eric Hibbard and Laszlo to create a spread of outstanding issues and
circulate
among the workgroup. (Due by June 6th)
* Jim to investigate a Wiki for the work group (Due June 6th)
* Serge to send P1619-D5 to the work group (done)
* Lazlo to write up a PAR proposal by June 6th
* Shai to define 'shared media' for the spreadsheet (done)
* Serge to merge Shai's definition into the glossary after IEEE finishes
editing.
* Laszlo to set up next conference call through Seagate, or to tell the working
group that Seagate cannot host the next meeting.
