# IETF 2023 Post-Quantum Use In Protocols (pquip) Work Group

[toc]

---
### [PQC ietf 原版筆記參考](https://notes.ietf.org/notes-ietf-118-pquip)
---
### PQ IN X.509
[pqc_hackathon_results_certs_r3](https://ietf-hackathon.github.io/pqc-certificates/pqc_hackathon_results_certs_r3.html)
- [PQ INX509 interperability project](https://github.com/IETF-Hackathon/pqc-certificates)
- PQC Algorithm testing
- Defining a prototype
- `Java, Rust...`
> Every provider can create their own artifact in .zip file
- 目的
- Giving Algorithms(Creativity)
- Testing
- Not **creating Protocols**
- Interoperable OID Mapping Table
> 
- Tested Algorithm
> 
- Compatibility matrix sample
> 
- 至今的成果
> 

> 

> 
- PQC Migration Mechanisms
> 
- Future
- NTRU, Hash based PQC 可能會加進去標準內
- Q&A

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 PQC Traditional Hybrid Schemes
[draft-ietf-pquip-pqt-hybrid-terminology](https://datatracker.ietf.org/doc/draft-ietf-pquip-pqt-hybrid-terminology/)

- Aims
- Ensure Consistency across different protocols, standards and organisations
- Make it clear what security propertiews a particular hybrid construction claims
- Enable esier comparison of solutions
- 至今工作
> 
> 
- FAQ
> 
- Q&A

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
[draft-ietf-pquip-pqc-engineers](https://datatracker.ietf.org/doc/draft-ietf-pquip-pqc-engineers/)
- Aims
- explains why engineers need to be aware of and understad PQC
> 
- 至今工作
> 

> 

> 
- Q&A

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
[draft-hale-pquip-hybrid-signature-spectrums](https://datatracker.ietf.org/doc/draft-hale-pquip-hybrid-signature-spectrums/)
- 動機
> 
xf
> 
- Goals
> 
- Approaches
> 

> 
- Q&A

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: 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
[draft-vaira-pquip-pqc-use-cases](https://datatracker.ietf.org/doc/draft-vaira-pquip-pqc-use-cases/)
- Introduction
> 
- Objective
> 

> 
- Future
> 
- ***USE CASE EXAMPLE***
> 

### Comparison of Hybrid KEM drafts across WGs
- Draft Comparison
> 
> intended to lower 3 draft
- Hybrid Algorithms used on these drafts
> 
- draft
> 

> 
> 

> 
> 

> 

> 
- Summary
> 

> 
- Q&A

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

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

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?

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.