Release Meeting Minutes/2009-12-15

Steve Buckley, Will Fiveash, Thomas Hardjono, Sam Hartman, Luke Howard, Greg Hudson, Robert Relyea, Zhanna Tsitkova, Tom Yu

Complications with using non-extractable keys in PKCS#11, etc. An attacker who gains control of a crypto module could get the module to produce the derived keys by encrypting chosen plaintext, given our KDFs. Robert says keys can be "derive-only"; any key derived from a non-extractable key is also non-extractable. Some exploration of PKCS#11 set of KDFs ensues. It looks like PKCS#11 might not currently have all the KDFs that would be needed for Kerberos.

CCM changes word/block alignment for additional authenticated data, by prefixing a length encoding that's neither a multiple of the cipher block size nor common machine word sizes, causing potentially large performance penalties. Maybe prefix the additional data input to CCM with additional padding so the CCM length encoding puts things back on a block boundary.

How much modularity to provide for PRNG? Zhanna says our use of AES256 for Yarrow is overkill because of the use of SHA-1, which gives only 160 bits security. Some talk about performance impact. No evidence that Yarrow is a bottleneck. We can go to Fortuna (Yarrow's successor) in a future release, but probably not 1.8 due to time. Vendors may want to use their own (possibly FIPS-140) PRNGs.

Sam says anonymous pkinit is somewhat behind; the work was uglier than expected.

Questions about Projects/GSSExtras -- query_attributes? Is it parallel to some SSPI function?