From 7d219fb42900b345727b07724a07e6582bf67abd Mon Sep 17 00:00:00 2001 From: Nigel Jones Date: Sun, 26 May 2024 18:30:38 +0100 Subject: [PATCH 1/6] 2024-05-23 minutes - first part Signed-off-by: Nigel Jones --- meetings/2024-05-23/minutes.md | 165 +++++++++++++++++++++++++++++++++ meetings/index.md | 2 +- 2 files changed, 166 insertions(+), 1 deletion(-) create mode 100644 meetings/2024-05-23/minutes.md diff --git a/meetings/2024-05-23/minutes.md b/meetings/2024-05-23/minutes.md new file mode 100644 index 0000000..0b07c92 --- /dev/null +++ b/meetings/2024-05-23/minutes.md @@ -0,0 +1,165 @@ +--- +layout: default +title: 2024-05-23 TSC Meeting Record +parent: Meeting Minutes +grand_parent: PQCP TSC +nav_exclude: true +--- + +# 2024-05-23 TSC Meeting Minutes + +## Agenda + + Welcome +* Approval of [2024-05-09 minutes](https://github.com/pq-code-package/tsc/pull/53) +* Update on [TSC chair vote](https://github.com/pq-code-package/tsc/issues/52) +* Funding for [AWS ECS](https://github.com/pq-code-package/mlkem-c-aarch64/issues/34) / [Github arm runners](https://github.com/pq-code-package/tsc/issues/55) +* Security - PQCA workgroup / SECURITY.md & lists / [Github reporting](https://github.com/PQCA/wg-security/issues/2) +* Updates and observations from related communities: + * [PQCA](https://github.com/PQCA) + * [Open Quantum Safe](https://github.com/open-quantum-safe) +* Discussion - [What does 'assured' mean?](https://github.com/pq-code-package/tsc/issues/3) +* [Hackathons](https://github.com/pq-code-package/tsc/issues/31) +* Review status of sub projects: + * [mlkem-c-generic](https://github.com/pq-code-package/mlkem-c-generic) + * [mlkem-c-embedded](https://github.com/pq-code-package/mlkem-c-embedded) + * [mlkem-c-aarch64](https://github.com/pq-code-package/mlkem-c-aarch64) + * [mkkem-libjade](https://github.com/pq-code-package/mlkem-libjade) + * [mlkem-rust-libcrux](https://github.com/pq-code-package/mlkem-rust-libcrux) + * [documentation](https://github.com/pq-code-package/documentation) +* Review [open TSC issues](https://github.com/pq-code-package/tsc/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc): + + * any noteable progress + * topics for next meeting +* Any other business +* Next meeting / ongoing schedule + +## Introductions + +Rod Chapman introduced himself as a colleague of Hano's at AWS Cryptography Group with a particular interest in formal verification of PQC. He has previously build a formally verified implementation of Kyber. + +## Decisions + +## Discussion + +### Approval of 2024-05-09 minutes + +Nigel thanked everyone who'd reviewed the minutes. Naomi pointed out that a formal vote is not needed. We agreed to approve minutes via github in future. + +### Update on TSC votes + +Nigel confirmed that he was elected TSC Chair following the vote. + +### Funding for ARM jobs + +Matthias summarized that his team want to benchmark, which is where real ARM processors are needed. This should be automated so that we can compare over time. For regular testing emulation remains an option. + +hano noted that we need to know exactly what hardware we are running on. Git runners may be an option if we can find this out. Benchmarking will also be done on specific hardware boards. Graviton is an interesting target. + +We agreed bare metal instances were not needed - experience indicates using the virtualized environments are good enough - and a lot cheaper. + +Ry updated us that a board vote to allocate money for this (and requests from oqs) did not pass due to not reaching quorum, but those present were in favour. It's expected to pass. BuildJet is also an option & are easy to integrate. For Amazon the master services agreement needs to be used to arrange access. The intent is to have a budget of $10k to use across all options for PQCA so we don't need to keep going back with updated requests. Ry can also work with team to integrate dedicated hardware with github actions. + +Hanno noted this work isn't time critical, and also that in future there was a possibility of wanting to delve deeper with some super optimized code - discussion for another day. + +The team agreed to continue discussion via issues as this has been progressing well. + +### Security + +Nigel noted that liboqs recently enabled private vulnarability reporting in their github repositories and proposed we do the same in pqcp (including creation of a SECURITY.md). We agreed this was reasonable to do. + +### PQCA update + +Max gave an update on PQCA. He reminded the team of the current workgroups include security and CBOM which are both looking for anyone interested to join. For CBOMs we may be able to start cataloguing important projects. + +This week's PQCA TAC included a presentation from Dana Wang, OpenSSF on open-source security, scorecards etc. In the future we hope we can influence these scorecards to capture if a project is pq ready/compliant/has CBOM. + +There's also activity to get funding for mentorship, and support students doing masters/PhD to make contributions. Doug mentioned this was part of the original formation discussions to bring new talent in. + +Finally there is currently a vote for vice-chair open. + +Nigel mentioned scorecard work had started in OQS, and whilst we have scorecards in pqcp, there is action to act on the findings. + +The potential of needing funding for formal audits was also brought up, but Matthias felt there is a fair way off yet. Ry pointed out that Trail Bits has recently joined PQCA. Doug mentioned OQS had a call with TrailBits recently, and hopefully they'll be looking at some oqs code pro-bono. + +### Open Quantum Safe + +In addition to mentoring, audits (above) Doug pointed out that acting on scorecard findings takes engineering resources. + +Release 0.11 is being worked towards over the next month. Two likely inclusions will be stateful hash-based signatures, the Mayo signature scheme, and a formally verified Kyber implementation from libjade. + +A security issue was also reported which now has a patch. + +Ry pointed out that OQS has a [dashboard](https://openquantumsafe.org/dashboard) which can include links to openssf reports. Nigel mentioned if we benchmark this could be useful info to add. Max pointed out we need to ensure the content is actionable, ie we use it. + + + ### What does assured mean + + _to be written_ + + ### Hackathons + + _to be written_ + + ### Review of subprojects + + _to be written_ + +### Any other business + + _to be written_ + +### Next meeting / ongoing schedule + + _to be written_ + +## Action items + +Action items + +### Done (from previous minutes) + +* [X] Naomi to arrange TSC chair vote (this was completed) +* [X] Naomi to schedule next meeting / send out invites (this was completed) +* [X] All - what does high assurance mean for the embedded/arch64 subproject (discussion was arranged, will track via issues above) +* [X] Nigel to share links on project lifecycle discussions (this was added to previous minutes) + +### Old + +* [ ] Nigel to contact John Schanck about API needs +* [ ] Tiago, Matthias to Present API design/approach for embedded/arch64 (see [Issue 4](https://github.com/pq-code-package/tsc/issues/29)) + +### New + +## Recordings + +* [Recordings are available on your Open Profile page](https://openprofile.dev/my-meetings) under Past Meetings + +## Upcoming TAC meetings + +The next meeting will be scheduled in 2 weeks time - 1300 UTC on 2024-06-06 + +[Please check the calendar](https://pqca.org/calendar/) + +## Attended by + +### TSC voting members + +* [x] [Manuel Barbosa](https://github.com/mbbarbosa), University of Porto +* [x] [Hanno Becker](https://github.com/hanno-becker), AWS +* [x] [Nigel Jones](https://github.com/planetf1), IBM +* [x] [Matthias J. Kannwischer](https://github.com/mkannwischer), CHelpis Quantum Tech +* [x] [Franziskus Kiefer](https://github.com/franziskuskiefer), Cryspen +* [x] [Tiago Oliveira](https://github.com/tfaoliveira), Sandbox AQ +* [ ] [John Schanck](https://github.com/jschanck), Mozilla +* [x] [Douglas Stebila](https://github.com/dstebila), University of Waterloo + +### Additional attendees + +* Alex Bozarth, IBM +* Norman Ashley, Cisco +* Naomi Washington, Linux Foundation +* Ry Jones, Linux Foundation +* Yarkin Doroz, Worcester Polytechnic Institute +* Duc Tri Nguyen, Cryptography Engineering Research Group @ GMU +* Rod Chapman, Amazon Web Services diff --git a/meetings/index.md b/meetings/index.md index 583e012..174b527 100644 --- a/meetings/index.md +++ b/meetings/index.md @@ -2,6 +2,6 @@ A regular meeting cadence has not yet been established. -* 2024-05-23 : [agenda](2024-05-23/agenda.md) / minutes +* 2024-05-23 : [agenda](2024-05-23/agenda.md) / [minutes](204-05-23/minutes.md) * 2024-05-09 : [agenda](2024-05-09/agenda.md) / [minutes](2024-05-09/minutes.md) (kick-off meeting) \ No newline at end of file From 397fdfcc7e52857eb23cd5013314797a6aadf104 Mon Sep 17 00:00:00 2001 From: Nigel Jones Date: Tue, 28 May 2024 11:38:16 +0100 Subject: [PATCH 2/6] 2024-05-23 minutes - second part Signed-off-by: Nigel Jones --- .gitignore | 1 + meetings/2024-05-23/minutes.md | 76 +++++++++++++++++++++++----------- 2 files changed, 53 insertions(+), 24 deletions(-) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..722d5e7 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +.vscode diff --git a/meetings/2024-05-23/minutes.md b/meetings/2024-05-23/minutes.md index 0b07c92..be6ceda 100644 --- a/meetings/2024-05-23/minutes.md +++ b/meetings/2024-05-23/minutes.md @@ -10,7 +10,7 @@ nav_exclude: true ## Agenda - Welcome +* Welcome * Approval of [2024-05-09 minutes](https://github.com/pq-code-package/tsc/pull/53) * Update on [TSC chair vote](https://github.com/pq-code-package/tsc/issues/52) * Funding for [AWS ECS](https://github.com/pq-code-package/mlkem-c-aarch64/issues/34) / [Github arm runners](https://github.com/pq-code-package/tsc/issues/55) @@ -24,22 +24,24 @@ nav_exclude: true * [mlkem-c-generic](https://github.com/pq-code-package/mlkem-c-generic) * [mlkem-c-embedded](https://github.com/pq-code-package/mlkem-c-embedded) * [mlkem-c-aarch64](https://github.com/pq-code-package/mlkem-c-aarch64) - * [mkkem-libjade](https://github.com/pq-code-package/mlkem-libjade) + * [mlkem-libjade](https://github.com/pq-code-package/mlkem-libjade) * [mlkem-rust-libcrux](https://github.com/pq-code-package/mlkem-rust-libcrux) * [documentation](https://github.com/pq-code-package/documentation) * Review [open TSC issues](https://github.com/pq-code-package/tsc/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc): - * any noteable progress + * any notable progress * topics for next meeting * Any other business * Next meeting / ongoing schedule ## Introductions -Rod Chapman introduced himself as a colleague of Hano's at AWS Cryptography Group with a particular interest in formal verification of PQC. He has previously build a formally verified implementation of Kyber. +Rod Chapman introduced himself as a colleague of Hanno's at AWS Cryptography Group with a particular interest in formal verification of PQC. He has previously build a formally verified implementation of Kyber. ## Decisions +no formal votes + ## Discussion ### Approval of 2024-05-09 minutes @@ -54,7 +56,7 @@ Nigel confirmed that he was elected TSC Chair following the vote. Matthias summarized that his team want to benchmark, which is where real ARM processors are needed. This should be automated so that we can compare over time. For regular testing emulation remains an option. -hano noted that we need to know exactly what hardware we are running on. Git runners may be an option if we can find this out. Benchmarking will also be done on specific hardware boards. Graviton is an interesting target. +Hanno noted that we need to know exactly what hardware we are running on. Git runners may be an option if we can find this out. Benchmarking will also be done on specific hardware boards. Graviton is an interesting target. We agreed bare metal instances were not needed - experience indicates using the virtualized environments are good enough - and a lot cheaper. @@ -66,7 +68,7 @@ The team agreed to continue discussion via issues as this has been progressing w ### Security -Nigel noted that liboqs recently enabled private vulnarability reporting in their github repositories and proposed we do the same in pqcp (including creation of a SECURITY.md). We agreed this was reasonable to do. +Nigel noted that liboqs recently enabled private vulnerability reporting in their github repositories and proposed we do the same in pqcp (including creation of a SECURITY.md). We agreed this was reasonable to do. ### PQCA update @@ -80,7 +82,7 @@ Finally there is currently a vote for vice-chair open. Nigel mentioned scorecard work had started in OQS, and whilst we have scorecards in pqcp, there is action to act on the findings. -The potential of needing funding for formal audits was also brought up, but Matthias felt there is a fair way off yet. Ry pointed out that Trail Bits has recently joined PQCA. Doug mentioned OQS had a call with TrailBits recently, and hopefully they'll be looking at some oqs code pro-bono. +The potential of needing funding for formal audits was also brought up, but Matthias felt there is a fair way off yet. Ry pointed out that Trail Bits has recently joined PQCA. Doug mentioned OQS had a call with TrailBits recently, and hopefully they'll be looking at some oqs code pro bono. ### Open Quantum Safe @@ -90,33 +92,60 @@ Release 0.11 is being worked towards over the next month. Two likely inclusions A security issue was also reported which now has a patch. -Ry pointed out that OQS has a [dashboard](https://openquantumsafe.org/dashboard) which can include links to openssf reports. Nigel mentioned if we benchmark this could be useful info to add. Max pointed out we need to ensure the content is actionable, ie we use it. +Ry pointed out that OQS has a [dashboard](https://openquantumsafe.org/dashboard) which can include links to OpenSSF reports. Nigel mentioned if we benchmark this could be useful info to add. Max pointed out we need to ensure the content is actionable, ie we use it. + +### What does assured mean + +We reviewed the discussion so far in [mlkem-c-aarch64#37](https://github.com/pq-code-package/mlkem-c-aarch64/issues/37) + +Minimum could be to run tests properly, use test vectors, run static analysis. If going for higher assurance we should do more - ie formal methods to prove no undefined behaviour, constant-time verification. Later extending to assembly correctness. Maybe we also look into additional tooling like CBMC especially when working on highly micro-optimized assembly. + +'production-ready'- very dependent on user's requirements ie embedded system vs cloud-scale service. Other aspects - like supply-chain security, performance, portability, BOMs are part of this too. Different implementations will vary (ie libjade etc is higher). Maybe alpha/pre-releases have lower guarantees. What's needed is to explain and document. can raise the bar over time. + +Manuel clarified a thought early on was to establish a taxonomy - or at least a set of terms that describe the levels of assurance. + +Rod pointed out that other industry assurance cases (safety critical etc) go with 'principles based assurance', or 'evidence based assurance' whereby you make a claim, and provide evidence to support - that may include tool used. Also clearly state assumptions. We should aim-high as seen with libjade, or (proprietary) AWS. - - ### What does assured mean +It was also pointed out that having any version is out than waiting for perfection. - _to be written_ +Summary of characteristics discussed: - ### Hackathons +* run tests properly +* static analysis +* formal proof of no undefined behaviour +* provide assembly correctness +* formal audit +* constant time verification +* formal specification +* dynamic testing +* functional correctness - _to be written_ +Discussion & goal of creating list of terms/definitions to continue in issue & review progress in next meeting. - ### Review of subprojects +### Hackathons - _to be written_ +Very brief discussion about implementation-specific hackathons - not had additional developers getting in touch yet to join existing projects. + +### Review of subprojects + +Not discussed due to time. ### Any other business - _to be written_ +No other topics. ### Next meeting / ongoing schedule - _to be written_ +* Some concern that current time is very early for US west coast (0600)- though we also cover Taiwan. +* Alternate times an option +* As out of time agreed to schedule a 1-off meeting for 2 weeks time & discuss in issue/at next session. ## Action items Action items +* [ ] Nigel to open issue to agree long-term meeting schedule + ### Done (from previous minutes) * [X] Naomi to arrange TSC chair vote (this was completed) @@ -149,17 +178,16 @@ The next meeting will be scheduled in 2 weeks time - 1300 UTC on 2024-06-06 * [x] [Hanno Becker](https://github.com/hanno-becker), AWS * [x] [Nigel Jones](https://github.com/planetf1), IBM * [x] [Matthias J. Kannwischer](https://github.com/mkannwischer), CHelpis Quantum Tech -* [x] [Franziskus Kiefer](https://github.com/franziskuskiefer), Cryspen -* [x] [Tiago Oliveira](https://github.com/tfaoliveira), Sandbox AQ +* [ ] [Franziskus Kiefer](https://github.com/franziskuskiefer), Cryspen +* [ ] [Tiago Oliveira](https://github.com/tfaoliveira), Sandbox AQ * [ ] [John Schanck](https://github.com/jschanck), Mozilla * [x] [Douglas Stebila](https://github.com/dstebila), University of Waterloo ### Additional attendees * Alex Bozarth, IBM -* Norman Ashley, Cisco -* Naomi Washington, Linux Foundation -* Ry Jones, Linux Foundation -* Yarkin Doroz, Worcester Polytechnic Institute -* Duc Tri Nguyen, Cryptography Engineering Research Group @ GMU * Rod Chapman, Amazon Web Services +* Ry Jones, Linux Foundation +* Michael Maximilien, IBM +* Hart Montgomery, Linux Foundation +* Naomi Washington, Linux Foundation From a6c6e6a2723f2f2c40356b93e5619c126f3a9d18 Mon Sep 17 00:00:00 2001 From: Nigel Jones Date: Wed, 29 May 2024 10:18:37 +0100 Subject: [PATCH 3/6] 2024-05-23 minutes - update attendees from zoom record Signed-off-by: Nigel Jones --- meetings/2024-05-23/minutes.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/meetings/2024-05-23/minutes.md b/meetings/2024-05-23/minutes.md index be6ceda..fbe3173 100644 --- a/meetings/2024-05-23/minutes.md +++ b/meetings/2024-05-23/minutes.md @@ -178,8 +178,8 @@ The next meeting will be scheduled in 2 weeks time - 1300 UTC on 2024-06-06 * [x] [Hanno Becker](https://github.com/hanno-becker), AWS * [x] [Nigel Jones](https://github.com/planetf1), IBM * [x] [Matthias J. Kannwischer](https://github.com/mkannwischer), CHelpis Quantum Tech -* [ ] [Franziskus Kiefer](https://github.com/franziskuskiefer), Cryspen -* [ ] [Tiago Oliveira](https://github.com/tfaoliveira), Sandbox AQ +* [X] [Franziskus Kiefer](https://github.com/franziskuskiefer), Cryspen +* [X] [Tiago Oliveira](https://github.com/tfaoliveira), Sandbox AQ * [ ] [John Schanck](https://github.com/jschanck), Mozilla * [x] [Douglas Stebila](https://github.com/dstebila), University of Waterloo @@ -187,7 +187,9 @@ The next meeting will be scheduled in 2 weeks time - 1300 UTC on 2024-06-06 * Alex Bozarth, IBM * Rod Chapman, Amazon Web Services +* Yarkin Doroz, Worcester Polytechnic Institute * Ry Jones, Linux Foundation * Michael Maximilien, IBM * Hart Montgomery, Linux Foundation +* Duc Tri Nguyen, Cryptography Engineering Research Group @ GMU * Naomi Washington, Linux Foundation From c8edfbe8c6afff3f82dacb5eac5ca30e0695ac57 Mon Sep 17 00:00:00 2001 From: Nigel Jones Date: Fri, 31 May 2024 09:36:11 +0100 Subject: [PATCH 4/6] Update meetings/2024-05-23/minutes.md Co-authored-by: Hanno Becker Signed-off-by: Nigel Jones --- meetings/2024-05-23/minutes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2024-05-23/minutes.md b/meetings/2024-05-23/minutes.md index fbe3173..c0d6255 100644 --- a/meetings/2024-05-23/minutes.md +++ b/meetings/2024-05-23/minutes.md @@ -98,7 +98,7 @@ Ry pointed out that OQS has a [dashboard](https://openquantumsafe.org/dashboard) We reviewed the discussion so far in [mlkem-c-aarch64#37](https://github.com/pq-code-package/mlkem-c-aarch64/issues/37) -Minimum could be to run tests properly, use test vectors, run static analysis. If going for higher assurance we should do more - ie formal methods to prove no undefined behaviour, constant-time verification. Later extending to assembly correctness. Maybe we also look into additional tooling like CBMC especially when working on highly micro-optimized assembly. +Minimum could be to run tests properly, use test vectors, run static analysis. If going for higher assurance we should do more - ie formal methods to prove no undefined behaviour (e.g. using CBMC), constant-time verification. Later extending to assembly correctness. 'production-ready'- very dependent on user's requirements ie embedded system vs cloud-scale service. Other aspects - like supply-chain security, performance, portability, BOMs are part of this too. Different implementations will vary (ie libjade etc is higher). Maybe alpha/pre-releases have lower guarantees. What's needed is to explain and document. can raise the bar over time. From 1a1393ab35c7544a340cbfb535dc6ee6ad91e6bb Mon Sep 17 00:00:00 2001 From: Nigel Jones Date: Fri, 31 May 2024 09:36:27 +0100 Subject: [PATCH 5/6] Update meetings/2024-05-23/minutes.md Co-authored-by: Hanno Becker Signed-off-by: Nigel Jones --- meetings/2024-05-23/minutes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2024-05-23/minutes.md b/meetings/2024-05-23/minutes.md index c0d6255..4cadfba 100644 --- a/meetings/2024-05-23/minutes.md +++ b/meetings/2024-05-23/minutes.md @@ -104,7 +104,7 @@ Minimum could be to run tests properly, use test vectors, run static analysis. I Manuel clarified a thought early on was to establish a taxonomy - or at least a set of terms that describe the levels of assurance. -Rod pointed out that other industry assurance cases (safety critical etc) go with 'principles based assurance', or 'evidence based assurance' whereby you make a claim, and provide evidence to support - that may include tool used. Also clearly state assumptions. We should aim-high as seen with libjade, or (proprietary) AWS. +Rod pointed out that other industry assurance cases (safety critical etc) go with 'principles based assurance', or 'evidence based assurance' whereby you make a claim, and provide evidence to support - that may include tool used. Also clearly state assumptions. We should aim-high as seen with libjade, or AWS' s2n-bignum. It was also pointed out that having any version is out than waiting for perfection. From 9f68af6038463d235a1ff51dd63382307d4c9568 Mon Sep 17 00:00:00 2001 From: Nigel Jones Date: Fri, 31 May 2024 09:40:44 +0100 Subject: [PATCH 6/6] 2024-05-23 minutes - add additional links from review comments Signed-off-by: Nigel Jones --- meetings/2024-05-23/minutes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meetings/2024-05-23/minutes.md b/meetings/2024-05-23/minutes.md index 4cadfba..7195660 100644 --- a/meetings/2024-05-23/minutes.md +++ b/meetings/2024-05-23/minutes.md @@ -36,7 +36,7 @@ nav_exclude: true ## Introductions -Rod Chapman introduced himself as a colleague of Hanno's at AWS Cryptography Group with a particular interest in formal verification of PQC. He has previously build a formally verified implementation of Kyber. +Rod Chapman introduced himself as a colleague of Hanno's at AWS Cryptography Group with a particular interest in formal verification of PQC. He has previously build a formally verified implementation of Kyber, [LibMLKEM](https://github.com/awslabs/LibMLKEM). ## Decisions @@ -104,7 +104,7 @@ Minimum could be to run tests properly, use test vectors, run static analysis. I Manuel clarified a thought early on was to establish a taxonomy - or at least a set of terms that describe the levels of assurance. -Rod pointed out that other industry assurance cases (safety critical etc) go with 'principles based assurance', or 'evidence based assurance' whereby you make a claim, and provide evidence to support - that may include tool used. Also clearly state assumptions. We should aim-high as seen with libjade, or AWS' s2n-bignum. +Rod pointed out that other industry assurance cases (safety critical etc) go with 'principles based assurance', or 'evidence based assurance' whereby you make a claim, and provide evidence to support - that may include tool used. Also clearly state assumptions. We should aim-high as seen with libjade, or AWS' [s2n-bignum](awslabs/s2n-bignum). It was also pointed out that having any version is out than waiting for perfection.