P1619, P1619.1 Meeting Minutes
==============================
Conference Call held on February 23rd, 2006 from 7AM to 2 PM
Attendees:
Gideon Avida decru
Matt Ball Quantum
Shai Halevi IBM
Laszlo Hars Seagate
Eric Hibbard Hitachi Data Systems
James Hughes StorageTek
Glen Jaquette IBM
curt Kolovson HP
Fabio Maino Cisco
Garry McCracken Kasten Chase
Richard Moeloer Neoscale
Dalit Naor IBM
Landon Noll Neoscale
Jim Norton JSNorton
Serge Plotkin Stanford
Doug Whiting HiFn
Rob ewan kasten chase
Dave Peterson McData
Graham Andrew Quantum (Not sure I've got this name right).
Meeting is called to order at 7:05 AM
Jim makes patent stament by posting patent slide to the list.
Landon Noll raises objections on Serge's affiliation at last meeting.
Gideon Davida declares Serge was not working for Decru at last meeting.
Serge declares he was working for Stanford.
MOTION A: Fabio moves to approve the meeting minutes, Serge seconds.
Minutes are approved by roll call: 8 yes, 1 nay (neoscale), 0 abstension.
Jim Norton (JSNorton) joins after this vote
Agenda
------
7.40 Document progression
8.00 Discussion on Disk Draft 4 p1619
- additional algorithms to be considered
- has this to be considered an interchange Standard
- Next Steps
11.00 Wide block encryption modes (1619.xyz)
12.00 Tape
- key transformation proposal
- membership of .1 != from 1619
- non combined modes
- IV optional size greater then 96
2.00 Review of action items
Motion B: Fabio moves to approve the agenda, Landon seconds and group
approves by acclamation.
7:50 Document Progression
-------------------------
If document is approved by the working group for editorail review, once
back from IEEE editorial board will be subject to ballot by a letter
ballot committee. There'll be a call for creasting the ballot commitee
as a public process. Comments are aligned by companies, Voting is done
by membership to IEEE. All letter ballot comments shall be addressed by
either being accepted ot rejected by the letter ballot commitee.
Dave Peterson, Dough Whiting, Curt kolovson, Matt Ball join the meeting.
This makes a total of 14 members with voting rights
8:15 Discussion on Disk Draft 4 p1619
-------------------------------------
The group discusses how this standard leads to interoperability, as
stated in the first para of section 1.1. There are different opinions
around the table, one point that finds some agreement is that the
standard is required, but not sufficient for interoperability. Goal of
the standard is best practices, and also to provide required but not
sufficient directions for interoperability.
AI #1, Serge Plotkin and Eric Hibbard: propose a re-phrasing of
import/export wording in section 1.1, third para. Eric will co-ordinate
with TCG at this purpose. Laszlo suggests to remove the word "ensure"
from the wording. (by march 24th)
Discussion on additional algorithms and modes that could be added to
1619. These modes can be added later to the standard as 1619.xyz. Laszlo
points out that access control, combined with this standard, would
provide a better security and would relax some of the requirements for
LRW (i.e. a simpler mode would be required if we assume protection
against unauthorized acces to raw data stored in the disk). More broadly
Laszlo points out that this standard would not benefit some of the
companies in the industry because where access control is taken care of,
there are cheaper mechansims to implement encrytpion that would provide
securty against the threats covered by 1619.
Motion C: Laszlo moves that the committee will consider additional
modes of operations including, but not limited to, those which assumes
access restriction and/or do not have the limitation of length
preservation", Landon Noll seconded. Motion passes in a roll call with
12 yes, 0 nay, 0 abstain, and 2 not present.
AI #2 Laszlo: propose extension to 1619 that address his concerns (hby
march 24th).
Group discusses how to move forward the current draft. Jim suggests that
there are still some issues pending on the document but some editorial
issues could be addressed during the editorial review. Landon reinforces
that this is close to what we need, but there are still issues that
needs to be discussed before editorial review to simplify the letter
ballot process.
Motion D: Jim makes the motion that "1619 D4 will be submitted to IEEE
for editorial review. Additional changes, if any, must be approved by
the committee before the letter ballot". Motion approved: 10 yes, 2 nay,
2 not present. JSNorton and Neoscale voted no, because they felt we
would have done better by addressing the issues that are still open
before sending the doc to editorial review. In their opinion this could
complicate the comment resolution process. Discussion occured later in
the day, and Heric Hubbard said that he would have voted yes, if present
at the motion.
AI #3, Serge Plotkin: forward the 1619 draft 4 to IEEE for editorial
review. (by March 10th)
AI #4, Jim Hughes: Prepare Letter ballot for 1619 (by march 17th)
12:00 Wide Block Encryption Modes
---------------------------------
The idea of a patent unencumbered wide block encryption mode may become
attractive again, given that 4kb blocks are now possible. Jim proposes
to prepare a PAR (to be duscussed on the reflector) for a wide block
encryption modes.
12:30 Tape Encryption
---------------------
Matt Ball from Quantum proposed on the reflector a mechanism for nonce
collision avoidance for different vendors based on HMAC in conjunction
with IEEE OUI. On top of that one could optionally add a media-ID
(serial number), but this could be kept optional. An issue with
serial-number media-ID can be purposedly impersonated and lead to
attacks. It would be nice to have the serial number as optionally
required. There's also a mode where the IV is random.
AI #5, Matt Ball: write text that clarifies implications of key material
quality on the security of the protocol. This is not going to be part of
the normative section, but rather in the appendixes. (by march 17th)
Discussion on type of key derivation. Matt pointed to an IETF draft for
key derivation in the work. Jim suggested we checks what Nist thinks
about it. Serge suggests that NIST key derivation standard is used
instead (NIST 800-90).
Landon proposes to allow IV larger then 96 bits (with a reasonable upper
limit). The advantage being that one can use a better entropy source and
a wider IV space (i.e. to offset non optimal random number generators).
There's a significant optimization for 96 bit IV in GCM, then larger IV
should be optional.
Need to make sure that the spec specifies that the original IV has to
be written on tape, not the result of the GHASH function used to derive
the nonce for the GCM machine.
Gideon pointed out that there're applications where you want to
authenticate the tape without reading. This might require a different
mode of operation where encryption and authentication keys are separated.
Next meeting (conference call) after we get 1619 back from editorial
review. Tentatively Thursday May 4th, from 8 to 2.
Meeting is adjourned by acclamation at 2 PM.
LIST OF ACTION ITEMS FROM THIS MEETING
--------------------------------------
AI #1, Serge Plotkin and Eric Hibbard: propose a re-phrasing of
import/export wording in section 1.1, third para. Eric will co-ordinate
with TCG at this purpose. Laszlo suggests to remove the word "ensure"
from the wording. (by march 24th)
AI #2 Laszlo: propose extension to 1619 that address his concerns (by
march 24th).
AI #3, Serge Plotkin: forward the 1619 draft 4 to IEEE for editorial
review. (by March 10th)
AI #4, Jim Hughes: Prepare Letter ballot for 1619 (by march 17th)
AI #5, Matt Ball: write text that clarifies implications of key material
quality on the security of the protocol. This is not going to be part of
the normative section, but rather in the appendixes. (by march 17th)
VOTES TO MOTIONS BY COMPANY
----------------------------
Motion -> A B C D
(accl)
HP np np np
IBM y y y
McData np y y
HiFn np y y
Hitachi y np np
Cisco y y y
Kasten Chase y y y
decru y y y
StorageTek y y y
JSNorton y y nay
Neoscale nay y nay
Seagate np y y
Quantum np y y
Stanford y y y
np: not present
