Session: CFRG Room: 212/213 Date: Friday 1120-1330 Minutes: Sean Turner Intro - David McGrew Remember that the CFRG is part of the IRTF. The IRTF is a sister organization to the IETF. The RFC editor publishes RFCs for the CFRG through a different stream than the IETF. The IETF Note well equally applies here. David introduced Kevin Igoe, who will serve as co-chair. Status - David McGrew There's one RG draft (draft-irtf-cfrg-cipher-catalog) There are also a couple of requests from the IETF Security Area: - TLS: draft-harkins-tls-pwd-02 and PAKE - JOSE: AEAD using generic composition of AES-CBC and HMAC-SHA - secure hashing using block ciphers Hash-base Password - Steve Bellovin Greg Shappiro - on slide 5: if you're using the HMAC user of the scheme do you need a revision #. Steve B - recommends using high quality password store. Shunichiro M (spelling sorry) - This scheme does not provide protection against replay attacks against sites. Steve B - you are correct. They're not going away just trying to make it go away. Shunichiro M - good for other things Steve B - it can help in replay attacks on challenge-based schemes but it wasn't designed for that. Greg Z - Have you considered password KDFs instead of HMAC? Steve B - Looked at PKCS#5. Doesn't really care about iterating this string with this function. If you want to substitute a different function fine. Ronald - how long can you go to implement this as a client even if the server had funny rules. Steve B - there are a bunch of browsers that do something like this, but there are sites that wouldn't except a hex string with no special characters. Tom Yu - Thinking it might be interesting to have some standard language for how passwords are made. These sites would be probably be the folks least likely to implement. David McGrew - the compromise of one server would reveal the password if weak passwords are used, so it is essential to use strong passwords with this scheme. Steve B - not disagreeing. draft addresses something about strong passwords. Stephen Farrell - How do you properly characterize when this is a good idea vs a bad idea. Steve B - he doesn't see a downside to doing this. It won't happen for a while. Stephen Farrell - it is a kind of thing that a whole bunch of people might jump on. Dragonfly: A PAKE Scheme - Dan Harkins Yoav Nir - there are no IPR? Really? Is it really enough different from speke that they won't go after. Dan - He thinks it is. Yoav Nir - with the way you convert pad to bases- would that be drop and replaceable with steve's scheme? Dan - Probably not. Steve's is more of a ... Steve B - they're complementary Ed R - Why the not use what IEEE already had defined in P1363 [see http://grouper.ieee.org/groups/1363/Research/Schemes.html] Why are you proposing a new one? Dan - There were IPR issues on a lot of the IEEE. The ones that were symmetric had IPR. The other ones were a bit freer but they had defined roles (i.e., only good in some circumstances). Maybe I overlooked 1363 scheme. Steve B - I would not like be as sanguine about the IPR schemes. Steve B - Would be a little worried about the browser user interface might cause a problem. Dan - That's a good point (2nd). One the IPR, the SPEKE claim is that a pad is used with DH. This doesn't use DH so É Steve B - It all matters about how it's sold by the lawyers. Dan - It'll all get decided in court. Joe Salowey - The difference between the scheme and SRP. Here both sides need to have same secret. In SRTP one side has a verifier that can't be used as the client. Dan - the server does has some stuff. In my scheme the need to have the same thing. Joe - could you scheme be made to be like SRP. Kevin - In the generation of the pwd and EC, there's a random Dan - the random had complained that the loop was susceptible to a timing attack. Added a counter that's going to through the loop. Kevin - if you failed to the loop then the pad wouldn't be used. Dan - I'll take a look at it. General discussion about PAKE: Rene S - I think it would be cool to use string to point on a curve as opposed to random. Kevin - something like they use s-k? Dan - doesn't that mean the curves have to have characteristics Rene - there's the usual IPR caveat. Yutaka (sp?) - HTTP2.0 is looking for authentication schemes to be used in HTTP 1.1 or 2.0. We need to propose something. He's proposing a PAKE scheme as a proposal. Stephen F - They're not looking for PAKE schemes. They're looking for authentication schemes David McGrew - do they have requirements written down? Stephen F - no The OCB AUthentication Encryption Algorithm - Phil Rogaway David - Were Intel's NI used during speediest? Phil - These examples use them and optimized OpenSSL. Rene S - What was on the horizontal axis Phil - byte lengths of messages Rene S - why he's asking. If we have to switch off zigbee - it would help to show really small sizes. Phil - David McGrew had a internet data mix and they used that. Phil - He'd like to see it move forward as an informational. David - How many people have read it - 3. David - How many are willing to review it - 8ish. David - Any objections to taking this on as a CFRG draft? silence Kevin I - We want additional authenticated data because we want to leave some in the clear. Phil - The associated data wasn't shown in the data, but the data is being processing in the auto through a scheme. Kind of like a Carter-Wegman code. Dan - Slide 16. Is he reading it right that GCM takes more time than CCM? Phil - You are reading it correctly. Tom Yu - Is it possible to run this algorithm on line if the data is intersperse with the data. Phil - It can. Tom Yu - Some MS proprietary protocol uses interspersing like that Phil - A significant part of the design was to allow for an elegant API. Cipher Suite on the Internet - Sean Shen ? - This is a good first step for this document. Do you have any idea for the direction of this document? Should this document include other than symmetric ciphers? Sean S - Going informational. Most people are using symmetric algs. David - Think we need to just focus on symmetric algs now and look at asymmetric algs later. Maybe we could do it with a separate draft. ? - People from academic rooms should be used. Sean S - We include more folks. Stephen F - It kind of implicit indicate what get used. But, if you could find a way that to be a bit more strong about your recommendations - like this is used and should be used this isn't and it's vanity crytpo. Tom Yu - Could you list attacks against work against partial/full? Stephen F - Is the intent to turn it in to an RFC. David - I would like it. Stephen F - It's hard to publish cfrg RFCs. ECC Considerations - Rene Struik David - All discussion points are interesting Stephen F - To the extent that this leads us to more encumbered things that would be bad. Rene - As a CFRG need to advocate the best we can get. Stephen F- We just need to be clear.