CFRG ---- 13:00-1500 Salon B Preliminaries ------------- Agenda changes. Note well. Dave McGrew steps down as co-chair. Kenny and Alexey are new co-chairs. WG Status --------- OCB AED published as RFC 7253 New work item: draft-nir-crfrg-chacha20-poly1305-06 Chairs reviewing status of draft-irtf-cfrg-dragonfly-04 New curves for TLS to be investigated. Presentations ------------- "ChaCha20 and Poly1305 for IETF protocols" ------------------------------------------ Yoav Nir presents Dave McGrew: Why not just AE? Yoav: That is what people wanted. Andrew Drewso?: Performance compared to AES? Yoav: Adam had some slides on TLS AES GCM w/Intel special instructions: 900Mb/s vs. 500MB/s with ChaCha. W/no special instructions, half of that. Yoav: Sandy Bridge 1272Mb/s, 700Mb/s w/o. Yoav: Servers are going to have hardware optimization. Key Bradnemier?: A lot chips are going to have AES. Yoav: Phones do not have hw acceleration for crypto. Paul Hoffman: Newer phones will have hw support. Bob Mascus: Support in the high-end network devices. "Hash-Based Signatures" ----------------------- Dave McGrew presents Alexey: Would you like to have this accepted in the RG? Dave: I would like it to do be included. Alexey: Will bring it to the list. "Challenge-Response mechanism" ------------------------------ Rifaat Shekh-Yusef presents Paul Hoffman: Speaking as co-chair ipsecme. We went through the PAKE wars. Gave up on the PAKE. People will bring up IPR, which is faster, etc. Never again. Col Macra?: Workshop on challenge-response mechanisms. Rifaat: Key derivation on the mailing list? "ECC protocols and standards" ----------------------------- Tanja Lange presents Dave McGrew: Can you comment on ephemeral DH checks vs. static DH checks? Dave McGrew: Ephemeral DH key would never get reused. Tanja: If keys are used strictly one-time only several of these attack do not apply, however, implementations _do_ reuse keys and get in trouble if the curve needs extra checks. Stephen Farrell: One of the more clear presentations on ECC, thank you! Deterministic Generation of Elliptic Curves ------------------------------------------- Brian LaMacchia presents Stephen Farrell: Working with all existing protocols is too big of a scope. Stephen: Working with TLS is OK. Brian: Want to focus on ECDSA. CA infrastructure. Ekr: Not just concerned about ECDSA, ... Craig Costello presents EC Research Mike Jones: Do you have numbers for ECDSA? Craig: 128 bit - 76k cycles, verify - 198k cycles. Tanja: I have to contradict you on speed. Floodyberry--Langley Curve25519(*) software for ECDHE, SA, etc. is faster than yours. Tanja: Regarding code reuse: the Weierstrass arithmetic is only a small part of the code, long integer arithmetic for finite fields takes more space and would be replaced for using other primes. Furthermore, it's the Weierstrass arithmetic that has all the implementation problems, so we don't want to reuse that code. PHB: Would like TE as it is not backwards compatible. Stephen Farrell: Any code change is not much of a concern. Yoav: The hard part is pushing out the code. Ekr: Code base is different than ECC. What wouldn't be compatible with this? Brian: Both would be compatible between TE and Weierstrass. (*) https://github.com/floodyberry/ed25519-donna "Curve25519 and Curve41417" --------------------------- D J Bernstein presents Adrei: Choice on prime, not 2^256. Bernstein: You have the closest to the power of 2 for the best performance. Andrei: Your'e not just talking about platforms that are doing shifts and adds? Bernstein: Yes, but some times it's for bigger platforms as well. Andrei: What about the security of 2^255-19? Bernstein: 2 ^ 251 is sufficient in the foreseeable future. Dan Brown: Is the coefficient dependent on performance? Bernstein: Small difference in performance. A few percentages. Craig Costello: ECDHE: when using Montgomery ladder does have performance impact. Bernstein: Avoid conflating interoperability/implementation issues. Bernstein: One question is what you need to send on the wire. Another question is what options you have available internally for a fast implementation. Brian: Primes: higher or lower. Dropping prime with each bit improves performance. General ECC Discussion ------------------- Tim Polk: Would like to talk about NIST's ECC work. Tim: All of the current set of curves are public. Doug: Not to consider a prime that is not aligned to an 8 bit boundary. Stephen Farrell: Clearly good ideas on curves, not to be hashed out in the TLS WG. Stephen: Pick one for each purpose. Interoperability with protocols is a concern. Sean Turner: Key agreement draft done. Compatibility with ECDSA needs review. Brian: All 6 curves in NUMS. TLS could have ~3. Dan: Compatible with all curves under discussion. PHB: Algorithm + key parameters, not talking about ECDHE, we're talking about a set of curves. Makes a huge difference of how this protocol is using this. Brian: Deterministic procedure on how the curves were generated is important to the RG. Dan Brown: Want to know if TLS wants support to static DH. Ekr: Very little use of static DH. Tanja: I'm all for using different curves but it's important to have a secure implementation, so don't replace with other Weierstrass curves. Brian: It is important to have a consistent way of generating curves. AOB ------------------- Wendy Seltzer: W3C crypto: Security considerations, what should and should not use.