PQUIP WG IETF 119, Brisbane 2024-03-19, 1730-1830 Minutes do not include what was read on the slides, only the mic line Post-Quantum Cryptography for Engineers, Aritra Banerjee https://datatracker.ietf.org/doc/draft-ietf-pquip-pqc-engineers/ No questions Terminology for Post-Quantum Traditional Hybrid Schemes, Flo Driscoll https://datatracker.ietf.org/doc/draft-ietf-pquip-pqt-hybrid-terminology/ Mike Ounsworth: Should we remove some of the academic-y stuff that has been coined in the last year? Strip it down to the things that are more stable Flo: Good point. The most academic stuff is about signature spectrums Is in a different draft, so not much would be lost removing that from here Stephen Farrell: Some of these form of hybrids are anti-patterns It would be good to have a name for those Flo: Naming things that people want to use is useful, even anti-patterns Hadn't thought about this before Hybrid signature spectrums, Britta Hale https://datatracker.ietf.org/doc/draft-hale-pquip-hybrid-signature-spectrums/ No mic line Post-quantum cryptography migration use cases, Alexander Railean https://datatracker.ietf.org/doc/draft-vaira-pquip-pqc-use-cases/ ?: Is this just about signatures? Alexander: Yes, we scoped it down to that Hash-based Signatures: State and Backup Management, Thom Wiggers https://datatracker.ietf.org/doc/draft-wiggers-hbs-state/ No mic line Composite vs. Parallel Signatures, Mike Ounsworth and Orie Steele Tiru Reddy: What happens if a hacker removes one of the signatures? Orie: You have two signerInfos that are cross-linked Mike: If you strip one out, you have a signerInfo that says "you should also see that other signerInfo" Aron Wussler: In OpenPGP, this is the hot topic for the meeting tomorrow morning This is the authors' proposal, but we have had 100+ emails on it Mike: That's also true of the LAMPS draft Stephen: I was going to be a smart-ass and ask you to put up the slide on combinatorics, but there isn't one. Slide 19: By saying that it puts responsibility on crypto developers, you're ignoring the complexity you are putting on people deploying things We end up with dozens of different codepoints for all different purposes Could make interoperability worse and security worse Hasn't been weighed in these discussions Implementing key management systems with that many options is a lot of complexity that is not shown on this slide Orie: The only way to avoid this is to say "here is the one or two you can do" But you can't stop people from deploying whatever they want Russ Housley: We do not have the combinatoric explosion problem the higher up you go Whatever we do in the crypto layer, we need to be sure it works in all of these environments so that one crypto library works in all of them Aron: Not worried about the combinatorial problem Is worried about having to do signatures on many levels, not reflected on these slides Mike Prorock: Worried about hearing "let's let implementers at the library level handle it" Implementation bug nightmare Likes Orie's idea that we need good guidance from CFRG Maybe they will say that we don't want to touch some of this at all Orie: Learned recently we can't dispatch stuff to CFRG Rohan Mahy: Not a fan of having every combination or a large number of combinations If there are any combinations that include RSA, we should have a much higher bar of an existence proof that it will be useful When people say "we're just going to add this thing on the outside" the reasoning falls apart Paul: This isn't a draft, it's a "what do we want to do". Closing, Paul Hoffman We might have one or two interims in the coming months Not clear what they are or when they are, that will be discussed on the list Stephen: Echoing Aron from before, OpenPGP is discussing some of this tomorrow One of the interesting things is figuring out how to get forward consensus Mike: What do the protocols need as security properties Make a statement, then see what matches