Crypto Forum Research Group Friday 8 April 2016 morning session Chairs: Alexey Melnikov (present) & Kenny Paterson ========================================================================== CFRG status (Alexey) - 15 mins ========================================================================== [agenda; note well] [document status, from slides] XMSS: Extended Hash-Based Signatures is in RGLC; please review other PAKE documents will not be finished until the requirements document is finished. Argon2 just accepted as a CFRG work item. It could be useful for openpgp. W3C asked for help with the webcrypto algorithms document. No update since the end of last year. 6090bis: now that we are done with most major elliptic curve work, it's a good time to revive this one. Crypto Review Team was suggested by Stephen Farrell earlier this year. Many people are asking to publish RFCs for national crypto; sometimes it goes to AD, or CFRG, or directly to ISE. Good to have a team of people to give consistent reviews and get a state of the art for algorithms in use. [CFRG Crypto Review Panel slides] Basic problem chairs have is that documents only get reviews if there is big outcry or big excitement on the list, so it's hard to get reviews in a reasonable timeline and get consistent reviews. Sort of like a mini-directorate as different IETF areas have. Panel review not a requirement before publishing or accepting as CFRG document. [discussion slide] Vasily Dolmatov: original idea was to make public review for MTI algorithms necessary. This idea is quite good since MTI algorithms will be used for years. There should be extensive public review on it. The proposed panel should review all crypto in IETF. This has nothing in common with the needs of the security area. We require public review, not some kind of appointed panel of reviewers and we require review of MTI algorithms not all text related with crypto. A lot of crypto specialists exists in the world, the very small subset of it is participating in IETF. So review panel could not provide objective review. I would like to remind that the home page of the IETF says that the IETF does not try to overcome any protocols which are used in the internet but do not belong to the IETF. yoav nir: I think I've wrapped my head around it. Let's try an example Suppose someone comes in with a calina cipher, of the Ukranian government what is th epanel supposed to do with this cipher? Say it's broken? Alexey: find existing research, point out if there are any known analyses of it, both positive and negative; not a request to do original research or pick on spelling nits. yoav: how is that different than sending it to the CFRG list and asking if there is stuff? Do they also look at document quality? alexey: yes, document quality is a key thing to look at. The document should be readable and implementable. stephen farrell: great idea; well-informed literature review, plus whatever guidance we can offer. Rather than depending on the kindness of strangers, having a set of people willing to do this stuff is a great idea and should help the IETF as well. alexey: This doesn't prevent any extra review or discussion on the CFRG list. It's fine for rough consensus on the list to disagree with the panel. farrell: example is the coda signature thing; document in IETF wanted to be stds-track in MANET; had never had any review. A year ago I asked CFRG if anyone had seen any review, and no one had, and we processed that information. Having a team setup would be really good. alexey: Very usefyl if we can't find volunteers on CFRG list, and having a dedicated person (group of people) would really help. stephen: not necessarly a decision, but provide an informed opinion. david mcgrew: great idea. Asked "how is different from current process?" Can identify resources in advance, so not a long wait next time to track someone down. A previous commenter was worried about transparency. You could write something up that would address transparency concerns; send writeup to the list not chairs, etc. alexey: mentioned in slides that review supposed to be public. If any concerns about particular reviewer doesn't like particular author, that's conflict of interest that chairs want to know about. The process is supposed to be fair in this respect. rich salz: also think it's a good idea. Some really good candidates for this group would be grad students with good current knowledge of literature, and as a second effect might get new blood involved. yaron sheffer: good idea. Quick suggestion: most of target audience of reviews do not understand details of resesarch, suggest that you adopt a more formal way of presenting the findings (more formal than secdir's ready/not-ready/xxx), so that people can get a feel after a few reviews how one algorithm/choice compares to another. something like level of research/review done high/medium/low, level of best practices used in this, etc. alexey: send mail to chairs to remind. not entirely sure how format would look like, but something uniform would probably help. alexey: looking for volunteers. self-nomination and nominating other people is a great idea. if you think someone would be good and they're not involved with IETF/IRTF send chairs email. we'll talk to people and try to convince them and whatnot. yoav channeling derek atkins: you can probably coordinate with sec-dir chair (Tero) for samples of the process and template format ========================================================================== XMSS: Extended Hash-Based Signatures (Andreas Huelsing, remotely) [draft-irtf-cfrg-xmss-hash-based-signatures-03] - 15 mins ========================================================================== [slides; no further questions/discussion] ========================================================================== Secure state management for hash-based signatures (David McGrew) - 20 mins ========================================================================== non-volatile cloning is unique to hash-based signatures, but volatile cloning breaks all sorts of things, so we don't try to deal with it here. Introduce a reservation step into the signature model, in addition to key generation, actual signing, and verification ========================================================================== Argon2 (Dmitry Khovratovich, remotely) - 20 mins ========================================================================== mcgrew: thanks for bringing your work to Internet community if we use H other than blake, would the blake compression scheme be used internally? dmitry: yes. original compression function is like one round of blake and we added multiplications there, so it's not one round of blake, so it mostly has to stay. Any 1024-bit wide implementation we could adjust, but we could also take several rounds per implementation of sha3, but that its more work mcgrew: I anticipate that people will only have sha2/sha3, and would like to use that; someone wanting to reuse. if the sha3 compression func worked that might be interesting dmitry: if we use sha3, it will probably be 3-4 times slower and thus less good. blake parallelize well, and otherwise very fast. kaduk: existing deployments sharing password files across different systems, which supports standardizing a password file format. stephen farrel: echo thanks for bringing; concerned that every extra parameter gives confusion. parameters in the hash function itself make things even worse. In the RFC that peopel would reference, i would like it to be one thing, and not a branch of things, since it would be confusing for other people. cutting it down to one thing would be more useful than one thing with N parameters alexey: make easier for engineers so we don't have to pick. farrell: at the same time not having to explain differences. dmitry: suppor that; our intention was to remove from users's control as many parameters as possible, leaving only time+memory. we would like to have single function for password hashing and that seems good (argon2i) farrell: please continue to resist tendency of people who ask for more parameters, and maybe go further to get rid of argon2d rich salz: echoing farrell, the last thing the IETF needs is more crypto families. don't want to say "this works everywhere" when it's not true, but some documents "this is how to use it" is good. If there's a document "this is a family", it doesn't really help. pick one that is the best for IETF uses, and document only that. ========================================================================== Quantum Resistant Cryptography discussion - 30 mins ========================================================================== alexey: David Mcgrew is playing devil's advocate today mcgrew: hash-based sig is motivated by post-quantum crypto. people are starting to take the possibility of quantum computers seriously, based on the NSA change in stance, and the amount of money going into building quantum computers. Try to provide security not just now, but into the future. mcgrew: what are the uses cases for PQC? I present three. (1) software/firmware signatures. router in the field for 15-20 years; when it boots, want to verify that it's running official software. Need to build a bootloader, which is not crypto-agile, and need a signature algorithm. "Router that hasn't been rebooted since 1998 ... also hasn't been updated since 1998" (2) long-term confidentiality; resist store-now-break-later attacks government uses require multiple decades of confidentiality kyle rose: for firmware signatures or hardware root-of-trust, tpm, sgx, etc. I don't expect the hardware to last long enough that this would be an issue. A device that's 15 years old, if you can't upgrade the firmware, you either get performance problems from scale or the device is just woefully out of date. confidentiality seems more reasonable if there are secrets that are valuable enough to keep them around for 30-40 years. it's not what I'd most be concerned about. mcgrew: infrastructure and IoT; you can't necessarily upgrade. kyle rose: I guess I don't have experience with hardware that lasts that long, so don't have ideas about hardware deployed in 1995 that's still running derek: yes, there are many devices that want firmware updates that will last 10-15 years tero: firmware signatures is not necessarily easy; talk to factory automation folks, they never update *anything*. IF something went wrong, the whole factory could stall. Even if they do, it's not automated. So the human doing things could verify authenticity in some other way, out of band. Also the company that makes firmware may have gone out of business, and the devices could be broken and unfixable. For confidentiality, in normal personal use, there is usually some sort of side-channel leakage; companies and such have more secrets and try harder to keep things secret for 30 years, but Andreas: some things can't replace hardware, like satellites derek: there are techniques to back out firmware updates if they fail dkg: add to firmware signatures, another reason not so important, if we talk about signature scheme used for 20 years in the future, than there is the idea that there is no intermediate firmware that is attacked. The chances are that over the course of 20 years, there are no signed firmware updates that have bugs in them are very small. A dedicated attacker could go back and install an old buggy firmware and attack those bugs. One more vote for long-term confidentiality as a long term kevin falk: a couple of areas related to signatures on large datasets; we're facing the question of validating machine-learning algorithms. large data sets become the software algorithms through training, so the integrity of data sets going into the future becomes more important. Also compliance for cross-validation mcgrew: data-set integrity is interesting; please provide details on list joe saloway: tend to agree with others that signatures on firmware is a concern, but not necessarily the major concern for me. certainly long-term confidentiality is a problem, in that data is out there now that is encrypted, and that will be vulnerable. Even for normal corporations, things 10-20 years in the future can still be bad. I also think that data-set integrity can be relevant. There may be statute of limitations that would make that not so improtant, but that's not many cases. (3) long-term secure remote management mcgrew: we kind of covered that with long-term confidentiality. Suppose building long-term (IoT) devices expected for 15 years that actually run 25 years. You log in remotely using, say, TLS, if there's a web interface. We mostly covered that already tim polk: these are great use cases, I'm all for working on PQC and people deploying it where they need to. I would caution that wherever possible, we'll still need crypto agility; the ultimate black swan is not the quantum computer itself, but rather the new quantum algotirhms; shor and grover are not the only smart people out there. don't want people to say "I'm doing PQC, I'm done", so still build in agility. mcgrew: yes, agility is crucial PHB: it's also worth considering our experience with computational breaks for DES. A password cracker with 350 billion cracks/second. These devices have been out there for a while, but I'm pretty sure that they're rarely used, only on a fraction traffic. When looking at defeating mass surveilance as opposed to targetted surveilance, there are other countermeasures we can do that still use standard crypto as opposed to PQC, like putting PFS in more places. The first 2048-bit QC will not be the day RSA falls, but rather when it can do them fast. mcrew: must do homework before that happens PHB: I agree, but we should understand the nature of the threat and all the ways that we can defeat it mcgrew: [new slide] where is PQC on the list of priorities It's important, we should work on it, but there are other priorities as well that might come first. stephen farrel: thanks for this slide; fantastic thing to do work here. Need to be careful to not oversell the threat; we have a lot of complext security solutions that don't get deployed, so we're the threat. work here should be done, but don't oversell it. We've had a number of WGs where we debate what Phill brought up; will ECC fall faster than DH, etc. The big problem now is non-adoption of security technologies because they're too complex, and adopting PQC might exacerbate that. dkg: we also suffer from over-complexity of security systems that are already deployed, and having things that we can't turn off or don't know (how) to, like logjam, ecdhe, etc. Adding additional complexity that does get deployed is also an issue. mcgrew: agree with comments about robustness; things like you describe are a bigger priority than QC joe saloway: continuing in that vein, the ability to be agile and sunset bad things is important. That falls into your robustness space and could be expanded. How do I know that my implementation is doing the right thing and not doing things it's not supposed to. Something of an implementation issue, but that's becoming more important. farrell: as well as algorithms, there's a useful piece of work. If properties of ciphers change, what is the impact of that on internet protocols? Could do this independent of thinking on quantum computers. If your key sizes get really big, what protocols break. As IETF works on next generation of protocols, could think about where fragmentation is needed, etc. russ housley: if you take cross-product of this and previous slide, it's important to think about what we would need to do if a QC were to become more likely/visible. Previous slide talked about signing for software; if we focus on QC-resistance of hash-based signatures, so that we can sign things in the face of RSA/etc falling. Right now if RSA fals, we have no way to deploy software with confidence that it's the right software being loaded. mcrgew: need to be sure that agility updates are secure. dkg: want to see statement about how we can mix post-quantum with existing crypto, that is no worse than existing, should PQC turn out to be bunk. Might be really easy, but haven't seen any academic analysis of that. mcgrew: there's a number of attempts at that. Scott and I+others submitted draft to ipsecme "postquantum pre-shared keys for ike". IKEv1 protects from QC if using large PSK; IKEv2 does not mix the PSK into all derived keys. This draft builds out PSKs on the side for potential future use. A lot of people say" that's great, but not a free lunch". Wanted a scheme with identity binding, to not make IKEv2's other security worse. So it's not a short draft. PHB: Folowing bob ross's comment, we need to distinguish PQC that is drop-in replacement for RSA, etc., but even if you came today with a perfect algorithm, we have to wait 10 years to have full confidence in it. Want to distinguish that from post-quantum [xxx]s. Say, with blockchains, where the workfactor goes up a lot to fake it. Also, kerberos. When I give S/MIME certs, I also give out a Kerberos ticket that connects up to my service. I'm not going to use it immediately, but I have it there if I need to bootstrap when RSA fails, so I can deploys stuff that's interesting. debbie cooley: Back to intermediate solution idea. Currently RSA/ECC, in future could mix in PSK; after that full post-quantum. Pre-shared key distrubition is the "non-free-lunch" part of that. We hear a lot about PSK for authentication, but that's only two-party, so the key distribution part is very difficult. Could allow PSK for a small community, not really authentication, just protection from post-quantum, that might reduce the work factor for mitigating the threat. There's an opportunity to design an easier-to-implement-and-deploy solution that gives what you want but minimizes the distribution problem. mcgrew: I agree with what you said, but want to hear more about the opportunity you see. post-quantum key as distincti from PSK in IKE? deb: Just use PSK for confidentiality, and use EC for authentication. As long as the community is not too big, you still get some protection. Authentication is real-time, so it should stand the longest. Could get away with classical longer, if only used for authentication. russ: to follow on PHB. When sha256 was standardized and we wanted to get people to go sha1-->sha256, I was security AD. We guessed 5 years; it took way longer. IF we're going to get quantum-safe sigalg out there and deployed, we need to get it going now. We can't wait; otherwise it will be time to deploy an we'll miss it. Let's get on with it. dkg: deb cooley's proposal of a PSK shared among the community; I'm not sure how much that really solves the distribution issue. I think it actually raises a different set of difficulties of distribution. Have to decide who is "in" and "out" group. For confidentilaity, that changes over time. PHB: re russ, not saying "don't do quantum sigs", but also have a plan B. I'm gonna have plan C and D. deb: dirty little secret is "Not always pairwise" for PSK pairwise would be great, but not often done today. As for russ's point, need to work on real system, but the more agile we can be, that can help in the meantime. kyle rose: re dkg, mix post-quantum in with classical keyex, there may still be value in using PSK. Just based on my cursory knowledge of literature, keyex is where we have the least confidence in existing post-quantum algorithms. That's where we need the most work at this point to gain greater confidence. richard barns: continuing on kyle, some of the combination deployments with two algorithms together can be useful for those objectives. Would be useful from my perspective as an implementor to have this group vet the combinatinos that they are being done in a sound way. mcgrew: great comments. Still have more slides... lots of standards that might need PQC what is easy/hard to do? I think we can get hash-based sig specs in a final deployable form within a year What can CFRG do to build standards and get them adopted? alexey: from chairs, NIST have medium-to-long-term view, and CFRG is more immediate. It's hard for CFRG chairs to say "come back in three years when this is studied more". We should definitely coordinate, but hopefully do something quicker. derek: there are also some braid-based algorithms coming down the pipe mcgrew: people come to CFRG and ask, "what should we do now?". "Use super-sized symmetric and be agile about asymmetric" might be good. andreas: Many PQC algorithms allow for different trade-offs. CFRG / IETF could collect performance requirements mcgrew: yes, and the size of keys and such. stephen farrell: something CFRG/community could do is improve confidence that we're not doing something already that's fragile. Demonstrating robust implementations would be good. I'm afraid that we're going to scare people into doing things that are worse than what they already have. Once we get people to take this seriously, they want to go out and do the latest thing. We want to make sure that's the right thing.