Draft Minutes from CFRG Meeting - IETF 93, Prague, Wednesday 22/7/2015 (Pi day)
===============================================================================

Meeting began 12:57

Alexey Melnikov went over document status.

There are now 2 co-chairs (Alexey, Kenny Paterson)

New Curves for TLS: The group has chosen 2: Curve25519 and Ed448-Goldilocks. Still need to choose signature scheme.

Joern-Marc Schmidt sent slides on requirements for PAKE algorithms. Alexey presented them.
First draft submitted. Please read and send feedback.

Extended hash-based signatures (Stefan Gazdag)
==============================================
Draft revised in-line with previous round of feedback.
No questions or comments.

Cheap Quantum-Safe Cryptography without Breaking Everything (Wiliam Whyte)
==========================================================================
Kenny Paterson: You've talked about a hybrid setting. Are you aware of any IPR.
WW: No, and I did search.
Tanja Lange: European project called PQCRYPTO (http://pqcrypto.eu.org/). Will have our first recommendations, which will include slowish algorithms. Would like to liaise with IETF and will publish a conservative portfolio; those algorithms
will be slower but more importantly have bigger keys than NTRU --
but have our confidence.
PHB: A pure symmetric system like Kerberos can strengthen the crypto. If you put all the data you got from random sources into TLS MS, you can add this as well, and then count how many bits of quantum resistance you need.
Logan Velvindron: hard for us (OpenSSH) to experiment with this because of IPR.
Stephen Farrell: Good topic for CFRG. You suggested CFRG consider a bunch of these. Is it going to be just NTRU in the end?
WW: It's a good thing to have.
SF: Formal liaisons with research groups is not something that is done.
TL: With Quantum all of RSA or ECC goes to zero or maybe 5 bits.
ekr: 5 bits is bad. Timeline of these things? implementers will do 1 or 2. Maybe we should wait and take our chances. Is this ready for prime-time.
WW: NTRU is stable. Others less so.
SF: Did you think whether a symmetric scheme like kerberos could fit?
WW: No.
Burt Kaliski, Jr : What about QS signatures? Do you want to include them as well?
WW: No. we're finding a response to the store-then-decrypt issue.
TL: If you're only sending boring stuff, you shouldn't care. But if you're sending something that will be interesting in 15 years, you want to deploy *now*. In ~3 years we might have something nicer.
DKG: Flexible implementations like browsers can implement *now* and that will help with things being out there sooner rather than later.
Chairs: hum if you think we should do this soon: yes (strong hum); no (crickets).

Intro to CrypTech (Karen O'Donoghue)
===================================


Elliptic Curve Signature Schemes
================================

Schnorr-Kravitz-Vanstone (Daniel Brown via Skype/phone):
??: IPR status?
DB: nothing on top of ECDSA

Ilari's proposal (Ilari via Alexey's phone, a portable speaker and a desktop mic):
(no questions or comments)

EdDSA for more curves (Tanja & DJB Live!):
ekr: does batch verification apply to different keys, or just same key?
DJB: both, but with same key it's faster (later clarification from TL: all speeds
reported are for different keys; it would be even faster with the same key)

Signatures (Watson Ladd; Martin Thomson presenting live):
MT: What does "Mandate double length scalar: no reason to think harder!" mean?
TL: He means that double-length is over-conservative enough to ensure that the scalar is uniformly distributed modulo the group order.

Challenge-response Schnorr (Mike Hamburg over Skype):
Bryan Ford: untrusted point parsing. On-curve check depends on what curves get matched to this scheme. If the only curves are curves designed so that the on-curve check is not critical then it is different.
MH: if you use an uncompressed representation, the check is more critical. 

DJB presenting about his python code comparing all the proposals:
Chairs: looking for discussion on deciding between them.
ekr: need important vs non-important distinctions.
SF: large pressure to get it out, so should be fast.
Kenny: want to be done in weeks, definitely before Japan.
Martin Thomson: I find Ilari's personalization desirable. I'm worried about its effect on things like PKCS#11. Can this be added to the other schemes?
DJB: We're amenable to consider, but want justification. Probably should be in the protocol.
ekr: what are inherent properties vs others. What are things that once you decide you can't go back?
DJB: Some of these features can be maintaining compatibility. Some of the security issues may need some time to understand. Should be spelled out. Implementation details are easier to see.
DB: I agree we should spend time studying the security.
KP: Do the theorems in your presentation have proofs?
DB: Yes for old ones, can write something for the new ones. Will send pointer.
DJB: I was hearing security claims in every presentation.
BF: Of all the X-resistance properties, how many of those would still exist if we ended up choosing a wide enough hash function such has SHA-3?
DB: they provide better collision resistance, but we can do this at the signature scheme level. If you use a wide enough path you might have slightly less performance.
TL: Putting a random before the message protects you against collisions in the hash function. Ladd and Brown proposals put the random first, which means they rely more on the hash function.
DJB: Do people like to use SHA-3?
Quynh Dang (NIST): SHA-3 was just signed off
SF: No enthusiasm anywhere in IETF for SHA-3. Here would be a first.

Ensuring Strong Keys (Phillip Hallam-Baker)
===========================================
RW: if they're both using a corrupted instance, you're still in trouble
PHB: the ergodicity adds up.
TL: How do you get the share to Alice if you can't generate numbers?
TL: ECDHIES is related and worth looking at for proofs and prior art.

Meeting concluded 15:32