CFRG Minutes IETF 99 Prague, Czech Republic July 18, 2017 15:50 - 17:50 Congress Hall I, Chairs: Alexey Melnikov and Kenny Paterson Materials: https://datatracker.ietf.org/meeting/99/session/cfrg Video: https://www.youtube.com/watch?v=U1eQIEG6YLU Scribe: Stephen Farrell 15:50 CFRG status update from CFRG chairs (5 mins; Kenny Paterson) 15:55 Re-keying Mechanisms for Symmetric Keys (10 + 10; Stanislav V. Smyshlyaev) https://datatracker.ietf.org/doc/draft-irtf-cfrg-re-keying/) Q&A: Yoav Nir: what about 3DES? Is it broken or just 64-bit? SS: not in scope of the draft, which is about ciphers that don't have any theoretical problems. Personal opinion: 3DES should not be in draft. YN: what about 32-bit ciphers? SS: not a problem if cipher has no weakness, just limit on how much data can be encrypted. Daniel Franke: I've been jokingly subtitling draft is "make 3DES great again". Bad life decision to revive 3DES, but this draft a good way to take a cipher where best attack is generic attack but where bounds are not great and make them more comfortable. SS: agree, thanks for reading the draft. How many have read draft? Maybe 20 Willing to review: Russ Housley + ??? 16:15 Verifiable Random Functions (10 + 10; Sharon Goldberg) https://tools.ietf.org/html/draft-goldbe-vrf-01 Q&A: Vladimir Smyslov: Performace slow vs. classical PRF ? SG: yes, you would not want to replace a PRF with a VRF. Bryan Ford: VRFs are nice, e.g. distributed password protection with trusted vs. untrusted public key, same as DCAF encoding? SG: not sure about DCAF, explains draft. KP: doesn't think one can use DCAF because you need discrete log? BF: thought it was a way of avoiding co-factor problems. Geoffrey Eskin: How many bytes in a proof and how fast? SG: not sure about performance, for 25519 proof is 256+128+256 bits long (Y,c,s). KP: Room, should CFRG adopt? Hum. Hum for adoption: reasonably loud hum. Hum against adoption: silence in scribe's ears. 16:35 Collective Edwards-Curve Digital Signature Algorithm (10 + 10; Bryan Ford) https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/ Q&A: SF: how would CFRG know that an RFC for this was done unless there are applications waiting for it? BF: we are using this for a number of things, would like to hear from more people, not sure. PHB: Very interested in this. Wants to split DH keys between TPM and elsewhere in application - can I do that as easily for signing? BF: this isn't a drop-in replacement for Ed25519. PHB: would like to re-use Ed25519 verify. BF: could be an open issue to add to the list, could redesign that way. Richard Barnes: combination here of crypto constructions and protocol considerations, how mixed are those here? Can they be separated? BF: crypto part is mostly done via papers from the literature, protocol part is TBD (in terms of decisions), CFRG seems like the place where those two skills are in one room. Russ Housley: interested (as PHB) in verification code re-use, but need all of public keys to do verification? BF: list of public keys needed somewhere but maybe not at verification function (but related key attacks mightn't make it easy), m-of-n cases also cause some variations; back and forth on this with RH, discussion of dealers, combiners, Shamir sharing, bit masks, set-up trade-offs, privacy and accountability trade-offs, etc. Vasily Nickolev: participants need secure connection with leader, how does that affect performance, is it still faster than CMS multi-signature? BF: once you get to 100s-1000s of co-signers, want to avoid all signers contacting leader; unlikely to be first use case anyway. Can avoid full complexity in the majority of applications. AM: Who would review this draft? About 6 people. 16:55 The Transition from Classical to Post-Quantum Cryptography (5 + 5; Kenny Paterson for Paul Hoffman) https://tools.ietf.org/html/draft-hoffman-c2pq-01 Q&A: PHB: interested in sizes and performance of options to know if/when it's practical to do some asymmetric PQ stuff or if do we need to fall back to Kerberos on a large scale. KP: not about algorithms, but timescale, so unlikely to have that in this document. David McGrew: don't discourage 256 bit AES. KP: I think it says that already in the draft. SF: +1 to PHB's desire for input on sizes and performances as known today for the possible options, sizes more important, doesn't need to be in same document nor finalised. KP: NIST competition will flush out concrete proposals with parameters, and then we should have ballpark/order of magnitude estimates. SF: good to have that information available, not necessarily in an RFC or soon. Daryl Piper: a lot of guessing here, not sure what the point is of blessing a draft that does not suggest a concrete way forward. KP: I'll let Paul respond to that. AM: How many are interested in working on this, reviewing it? 7-8 hands in room + 2 on jabber. How many say they think it's a waste of time and we shouldn't be doing it here: none. 17:05 Hash-Based Signatures (10 + 5; David McGrew) https://datatracker.ietf.org/doc/draft-mcgrew-hash-sigs/ See also: http://eprint.iacr.org/2017/349.pdf; http://eprint.iacr.org/2017/349.pdf; https://github.com/cisco/hash-sigs Q&A: Jeffery Eskin: it would be nice to have sizes of signatures and keys documented in the specification. DMcG: good comment. KP: I'm confused about the figures. DMcG: last column is the ratio. SF: in addition to size information, would be good to know the trade-offs, maybe a presentation at CFRG in future? DMcG: published code is decent wrt that; it's a long topic, would make sense to document some of the choices and trade-offs. Chairs noted request for last call. 17:20 KangarooTwelve (10 + 5; Quynh Dang for Beno�t Viguier) https://tools.ietf.org/html/draft-viguier-kangarootwelve-00 Q&A: Kyle Rose: takes 3 inputs, msg, len, string/label? We've argued about labels before as hash inputs. QD: I believe it's optional. KP: what does NIST think of this, in terms of standardising? QD: not sure about future, but in the past we adopted stuff from IETF, e.g. HMAC happened, CFRG curves being considered, so could happen who knows? Kangaroo12 security seems good but perf. is two times better than SHAKE128 for short messages, and much faster for long messages. It's one size fits all. 17:35 Two proposals: ECC mod 8^91 + 5 and DH mod 630(427!+1)+1 (10 + 5; Andrew Allen for Dan Brown) Q&A: Scott Fluhrer: what is the co-factor for the curve? DB: it's 72. KP: wrt rfc7919, why is this better? DB: RFC prime has special compact form; fewer symbols may leave less room for backdoor; den Boer reduction means CDH security closely related to DLOG security, not checked details for rfc7919 but expects proof to break down. AOB: None. 17:50 Close of CFRG meeting