P1619: Need a host for the June 7th meeting
It looks like Laszlo will be unable to host the next P1619 meeting.
Is there anyone else who could pick this up? I will probably not
be able to attend this meeting, so Quantum will not host it.
Jim, would Sun be able to set up a call-in?
-Matt
-----Original Message-----
From: stds-p1619@IEEE.ORG [mailto:stds-p1619@IEEE.ORG]On Behalf Of
laszlo@HARS.US
Sent: Wednesday, May 31, 2006 10:42 AM
To: SISWG
Subject: RE: Minutes from the P1619/1619.1 meetings on May 23rd, 2006
On June 7/8 I have to attend a business meeting, so I cannot host the
planned teleconference. I might be able to dial in, but not for the
whole duration of the teleconference. -Laszlo
> -------- Original Message --------
> Subject: Minutes from the P1619/1619.1 meetings on May 23rd, 2006
> From: "Matt Ball"
> Date: Tue, May 23, 2006 7:57 pm
> To: "SISWG" <stds-p1619@IEEE.ORG>
>
> (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.