# Post-Quantum Use In Protocols (pquip) WG   {#post-quantum-use-in-protocols-pquip-wg}

*   [About pquip][1]

IETF 118, Prague  
2023-11-10, 1300-1500 local time  
Sofia Celi (SC) and Paul Hoffman (PH), co-chairs

*   Note takers: Daniel Kahn Gillmor (dkg) and Mike Ounsworth (MO)

## Intro and Note Well - 5 min   {#intro-and-note-well---5-min}

MO wants his slides added to the agenda. Chairs will add him at the end.

## PQC Hackathon report - 5 min   {#pqc-hackathon-report---5-min}

*   John Gray (JG)  
    [pqc-certificates][2]  
    [pqc\_hackathon\_results\_certs\_r3][3]

PH encourages people to participate, even if not at face-to-face
hackathon

Kris Kwiatkowski (KK): which other algorithms?

JG: NTRU? stateful hash-based sigs? New NIST on-ramp sigs?

MO: the way to get an algorithm on the list is to submit it and get
someone else to test it. As long as we have one producer and one
consumer (pass or fail), then it'll be in the table. We also have
classical algos (RSA, ECC) to make sure the frameworks are functional.

## Terminology for Post-Quantum Traditional Hybrid Schemes - 15 min   {#terminology-for-post-quantum-traditional-hybrid-schemes---15-min}

*   Florence Driscoll (FD)  
    [draft-ietf-pquip-pqt-hybrid-terminology][4]

MO: This document is good just by existing. It's evolving. it would be
premature to close the draft, unless we need to avoid a MISREF.

Scott Fluhrer (SF): should treat this as a living document instead of an
RFC?

Guilin WANG (GW): There are more traditional alogrithms than just RSA
and DSA, which were mentioned in the draft. Please expand the text about
traditional algorithms.

FD: let's talk about this on the mailing list. Our current definition is
about using integer factorization or discrete logarithm. I don't know
that we want to refer to everything here.

GW: Multi-algorithm scheme ≠ Multi-component scheme

FD: i've tried to update the definitions based on your comments about
this on the list.

Phillip Hallam-Baker (PHB): EDNOTE 1 (distinguishing between source
authentication and identity authentication) is concretely useful. a
single X.509 chain isn't the only kind of certification.

FD: if you have specific thoughts, use cases, or text to propose, please
do.

PH: please propose text.

Roman Danyliw (RD): as AD, you can make WGLC, or you can hold it as a
living document; or, third option: you can go through WGLC but then park
it for some amount of time, to make sure that it's right until you need
it published.

PH: how about if a document depends on it?

RD: depends on whether references are normative or informative.
normative references to unpublished I-D will cause a MISREF. There's
also no harm in WGLC'ing it twice. Informative refs will not block
publication.

MO: I believe that every ref I've seen to this document in Informative,
so we may not have any examples of this problem.

SC: queue is closed, please take the rest of the discussion to the list.

## Post-Quantum Cryptography for Engineers - 15 min   {#post-quantum-cryptography-for-engineers---15-min}

*   Aritra Banerjee (AB)  
    [draft-ietf-pquip-pqc-engineers][5]

Deirdre Connolly (DC): upgrade from Kyber to ML-KEM changes the
commitment to the ciphertext. Kyber did commit to the ciphertext, ML-KEM
does not. I will propose some text.

PH: include some discussion about how we got there. Doesn't need to be a
deeply technical record, but it would be good to log it.

## Hybrid signature spectrums - 15 min   {#hybrid-signature-spectrums---15-min}

*   Deirdre Connolly (DC)  
    [draft-hale-pquip-hybrid-signature-spectrums][6]

SF: The draft doesn't contain a mention of hybrids that use black box
implementations of underlying signature systems.

DC: there's some stuff in there that implies it, but we can make it
explicit

SF: consider talking about pre-hashing: if the messae is hashed, and you
give the hash to both underlying algorithms, it might work.

JG: as one of the authors of the composite signatures draft, would a
draft in CFRG be helpful? CFRG draft shows theory and concrete
mechanisms; this draft shows overall ideas; and drafts in LAMPS,etc that
propose protocol-specific implementations.

DC: I have been hearing a request for a CFRG draft from multiple people.
This draft provides a list of possible constructions; perhaps we should
split those out into a CRFG draft.

Jonathan Hoyland (JH): Is there a notion in between weak and strong
where you can strip off one of the signatures but not the other?

DC / Britta Hale (BH): We believe that is Weak, but we could refine the
definitions to address this more specifically, for example define
EUF-SNS / EUF-WNS / SUF-SNS / SUF-WNS / etc.

Andrew Fregly (AF): does the draft talk about using different hash
functions?

DC: we should talk about including that in a CFRG approaches document,
probably not this one.

Thom Wiggers (TW): in all of these combinations, the algorithms are
likely not equal. having asymmetric non-separability could be useful
(being able to strip off one but not the other could be good). This has
implications for backwards compatibility.

DC: depends on which scheme goes first in each of these constructions.
concatenation is not an issue, but nested *is* an issue. we'll talk
about this with CFRG.

## Post-quantum cryptography use cases - 15 min   {#post-quantum-cryptography-use-cases---15-min}

*   Antonio Vaira (AV)  
    [draft-vaira-pquip-pqc-use-cases][7]

PH: it would be great to have people add their use cases to this
document

MO: we want to use these to motivate LAMPS

## Hybrid KEM comparisons - 15 mins   {#hybrid-kem-comparisons---15-mins}

*   Mike Ounsworth (MO)  
     [Comparison of hybrid KEM drafts across WGs][8]

(slide 2 bottom corner SHA3-256 should be KMAC256)

SC: still please talk with your lab when you are doing FIPS
certification. don't take these slides as authoritative!

dkg: does slide 5 include the identity of the algorithms themselves?

PH: this is not the room to workshop these drafts! MO is just giving an
overview here. it's a cfrg draft, take it up with cfrg.

SF: securit of this construction depends heavily on the TLS KDF and
won't be secure in other contexts.

MO: the fact that it's ephemeral is what counts?

SF: not just ephemerality, but the fact that the KDF for TLS also hashes
in the transcript.

PH: engineer's draft needs to include details like slide 8 (lack of
ciphertext commitment in DL-KEM compared to Kyber). it will help avoid
problems.

Rohan Mahy (RM): agree with PH: if it's safe, please tell us! if we say
nothing here, people will wander around looking for it elsewhere. please
tell the engineers the answer here!

## All other WG business - remainder   {#all-other-wg-business---remainder}

Orie Steele (OS): Mike asked about whether we need a full cross-product
with these different component algorithms. different WGs will stress
different points on that table. Can this WG coordinate or warn about
that?

RD: this is chartered to not make specs or do security evaluation. can
we adjudicate disagreements between WGs? probably not, but we can
connect them. the cross-cutting review here is great, but maybe it
triggers some action outside of this group. We might also take it up a
level to the SEC area or elsewhere.

PH: to be clear, exposing cross-cutting problems or concerns in this WG
*is* acceptable.

Renzo Navas (RN): i work with IOT, constrained environments. i'm trying
kyber in these constrained environments. I'll start with COSE or CBOR
maybe LAKE, etc. I'm just letting folks here know that this work is
happening.

Deb Cooley (DC): the NSA has a desire to get PQ algorithms fielded as
quickly as possible, because we see it as a real threat. We think you
should use your installed base (SHA2) as a way to bootstrap your
deployment. we find that hashes are very slow to migrate. we shut down
our last sha1 CA in november 2022, as an example. If there's no loss in
security or speed, we encourage the use of SHA2. we feel the security
properties of the two algorithms are very similar.

MO: is that a comment to IETF, or to NIST? If the ML's need SHA3
internally, then you need it anyway.

DC: comment here is because of comments from my colleague on the NIST
list. I'm trying to clarify comments that you might have read elsewhere.
2027-2030, we'll see that sha2-384 is fully deployed. we're pushing our
current smartcards to that hash, which means that you get sha2-512 for
free (we want to end up on sha2-512)

PHB: we're starting to use SHA-3 a lot as a KDF, and it has nice
properties as a KDF because you don't need to layer things. We need to
ignore the implicit thing that 3 is better than 2, the two hash families
are interchangeable.

DC: my point is that SHA2 is quicker to deploy than SHA3.

* * *

PH: please keep up work on the mailing list!

## Chair's summary   {#chairs-summary}

The two drafts that have been adopted by the WG presented in this IETF
meeting. Both are advancing and reaching consensus, but could be
potentially ever evolving.  
Hybrid mechanisms continue to be of ever importance to the post-quantum
migration: the 'Hybrid KEM comparisons' and 'Hybrid signature spectrums'
presentations emphasise that we still need to think about a what APIs
they should provide, and to clearly label which security properties they
give.   
Finally, as the migration to post-quantum cryptography continue,
post-quantum cryptography use cases need to be clearly stated. The
presentation of 'Post-quantum cryptography use cases' (and its draft) is
a line in this direction.



[1]: https://datatracker.ietf.org/wg/pquip/about
[2]: https://github.com/IETF-Hackathon/pqc-certificates
[3]: https://ietf-hackathon.github.io/pqc-certificates/pqc_hackathon_results_certs_r3.html
[4]: https://datatracker.ietf.org/doc/draft-ietf-pquip-pqt-hybrid-terminology/
[5]: https://datatracker.ietf.org/doc/draft-ietf-pquip-pqc-engineers/
[6]: https://datatracker.ietf.org/doc/draft-hale-pquip-hybrid-signature-spectrums/
[7]: https://datatracker.ietf.org/doc/draft-vaira-pquip-pqc-use-cases/
[8]: https://datatracker.ietf.org/meeting/118/materials/slides-118-pquip-pquip-hybridkem-comparisons