Security Area Open Meeting (SAAG) Minutes Meeting : IETF 74, Thursday 26 March 2009, 13:00-15:00 Location: San Francisco Hilton, Continental 4 Chairs : Pasi Eronen and Tim Polk Minutes : Jeffrey Hutzelman and Tero Kivinen (edited by Pasi) Version : 1 (2009-04-06) ---------------------------------------------------------------------- 1. Overview - ADs The ADs opened the meeting with a review of the agenda. ---------- 2. WG reports WG reports in email: pkix, nea, sasl, krb-wg, kitten, dkim, msec, emu Missing: keyprov, hokey, tls Eric Rescorla gave WG report from TLS (mailed just before SAAG). Sean Turner reported on KEYPROV. Tim reported on HOKEY: Short timeslot, productive meeting, 2 drafts being worked on, key management draft ready for WGLC, another one has more issues, quite bit of discussion, needs confirmation from the list. Not met yet: isms, ipsecme Not meeting this time (in email): btns, ltans, smime, syslog Syslog indicated that they might be rechartering away from sec area as the items are not security items anymore. Perhaps they are better suited for APPS area than OPS area. OAUTH bof: 2nd bof, initial charter proposal done on mailing list, still needs some rewording, and charter discussion might get finalized in next few weeks. KMART roadmap advertisement, more about this in Stockholm meeting. ---------- 3. Changes in NIST Recommendations and Requirements for Cryptographic Algorithms and Key Sizes At the End of 2010 (Paul Hoffman) Tim: NIST requirements only apply to federal goverment, currently you cannot configure current software to able able to conform the requirements. Sam Hartman: I'd like to object the form of the presentation. This is like someone coming to some other WG and telling what is vendor X's requirements. There is important content in this presentation. We are an international organization, not US Government, better structure for this presentation would have been that: this is what NIST is doing. Pasi: NIST requirements are important in US and other places, as people follow them even if they are not requirements for them. If there is other requirements for some other goverment, we would allow that too. We are not trying to say that NIST requirements are the right requirements. ---------- 4. SHA-3 Competition Update (Bill Burr) Eric Rescorla: Are you worried we're putting all our eggs in one basket with AES? Bill: If someone findes a way to attack the AES S-boxes... are we really better off if someone breaks AES but we still have a hash? ?: After "unexpected advances", there was some discussion of having different hashes for different purposes. What is NIST's view? Still one hash? Bill: Still open for new types of hashes. For SHA-3, we wanted a plug-in replacement for SHA-2. I tend to think the community isn't going to want two independent standards that do basically the same thing. There would have to be some reason. David Black: Digital signatures are where we have the most pain, but integrity MACs are probably the most common use; please don't lose sight of that by focusing on digital signatures. Bill: Fair enough, but digital signatures are the hard part, and keep thinking maybe UMACs are a better choice for integrity. ?: 32-bit is going to stay there, small devices. Sandy Murphy: There are lots of low-power networks out there, where even the 32 bits is beyond their capacity. ---------- 5. Randomized Hashing (Hugo Krawczyk) Eric Rescorla: Can you concatenate R to the hash output and RSA sign the result, instead of signing only the hash output and concatenating that to R? Because if so, you have a better chance of applying the new technique using the existing interfaces. Hugo: Yes, for RSA. David McGrew: Good work, glad to see it here. Can you quantify the security of SHA1-RMX? Hugo: Basically, if we were using SHA1-RMX, security is closer to HMAC than to digital signatures today. Massimiliano Pala: Are there any IPR issues? Hugo: I do not write patents. ---------- 6. Standardizing Key Derivation Functions (Hugo Krawczyk) Dan Harkins: You say hash function itself not suitable as an extractor, but in your generic extractor, you said you could have a key length of 0; aren't you then relying on the underlying hash? Hugo: Sure; you're relying on HMAC and on the underlying hash in any case. Dan: Is there some magical property which makes it OK to use this compression function as an extractor just because you're using it in an HMAC? Hugo: Yes, details in the paper. You can use AES in CBC mode as an extractor and as a PRF. ?: Don't you need a key? Dan Harkins: Hugo: Even in the case of CBC with a fixed key, you get a good extractor. In the case of hashes, even if your compression function is perfect, the hash is not an extractor, while HMAC is. Michael Williams: Pasi: It would be useful to have RFC that would specify some KDF. I would very much support standardizing this as separate RFC, so it could be referenced instead of cut-and-pasting KDF from, for example, IKEv2. ---------- 7. Threshold Secret Sharing (David McGrew) ?: Is there IPR? David: No IPRs that I know. Paul Hoffman: Talking about signing DNS root key. This requires auditing. Can this detect which m keys were used to reconstruct the secret? David: Let's take this offline. ----------------------------------------------------------------------