Minutes IETF119: pquip
minutes-119-pquip-01

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