FIPS 203 ipd v2?
Deirdre Connolly
Thanks!
Deirdre
Jacob Alperin-Sheriff
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/6643e6b7-ef48-47af-a1c7-f063a7dc9985n%40list.nist.gov.
Scott Fluhrer (sfluhrer)
I certainly hope they won’t do a second draft. Some of us are waiting with bated breath for FIPS 203 – another draft and comment period would delay things by at least half a year…
--
Mike Ounsworth
I’m not attending the NIST event this week because I guiltily took vacation, so sorry for not having the context.
On the surface, this seems like a “do it fast” vs “do it right” conflict.
Are the concerns with 203-ipd significant enough that they warrant another full review period? That’s still preferrable to living with half-baked crypto for the next 20 years.
---
Mike Ounsworth
From: 'Scott Fluhrer (sfluhrer)' via pqc-forum <pqc-...@list.nist.gov>
Sent: Thursday, April 11, 2024 10:50 AM
To: Deirdre Connolly <durumcr...@gmail.com>; pqc-forum <pqc-...@list.nist.gov>
Subject: [EXTERNAL] RE: [pqc-forum] FIPS 203 ipd v2?
I certainly hope they won’t do a second draft. Some of us are waiting with bated breath for FIPS 203 – another draft and comment period would delay things by at least half a year… From: pqc-forum@ list. nist. gov <pqc-forum@ list. nist. gov>
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB5444F5280AED819A619305E7C1052%40CH0PR11MB5444.namprd11.prod.outlook.com.
Deirdre Connolly
Ethan Gordon
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAFR824wJPL6O8wrWxhCtQ7nd91Q-qPX1Yje9%2BHiD%3DsaMBRzT5w%40mail.gmail.com.
Jacob Alperin-Sheriff
Deirdre Connolly
Simon Hoerder
I'm similarly not attending the NIST event, unfortunately, but I would
very much urge to avoid further changes to the algorithm beyond what was
announced today _unless_ there is a serious security issue. Getting
secure hardware implemented, taped-out and tested takes more than a
year. Any further delays to such projects will make it even more
difficult to meet the transition timelines from CNSA v2 for all affected
devices.
Another aspect is certification. Every change to the algorithm has the
potential to affect CAVP / ACVTS certification preparations. (Same for
other certification schemes, btw.) Again, anything that delays the
certification schemes will affect the ability to meet those transition
timelines.
On the other hand I also want to avoid half-baked crypto or badly worded
standards that allow for incompatible interpretations. I'd be ok with an
ipd v2 that clearly states no further algorithm changes will happen
_unless_ a serious security issue is found.
Finally, we should expect that there is a time frame this autumn /
winter where election related issues might affect government sign-off on
new standards. Not that I expect the standards to become a political
issues but when key people are either on the campaign trail or in care
taker positions until new appointments are made, sign-offs will be
difficult. I don't consider this point as a good reason to avoid an ipd
v2 but it's a timeline risk that I believe people should be aware of: We
just need to ensure that the standards are high enough priority to go
through the sign-off process no matter what.
Best,
Simon
On 11/04/2024 17:52, 'Mike Ounsworth' via pqc-forum wrote:
> I’m not attending the NIST event this week because I guiltily took
> vacation, so sorry for not having the context.
>
> On the surface, this seems like a “do it fast” vs “do it right” conflict.
>
> Are the concerns with 203-ipd significant enough that they warrant
> another full review period? That’s still preferrable to living with
> half-baked crypto for the next 20 years.
>
> ---
>
>
> *From:*'Scott Fluhrer (sfluhrer)' via pqc-forum <pqc-...@list.nist.gov>
> *Sent:* Thursday, April 11, 2024 10:50 AM
> *To:* Deirdre Connolly <durumcr...@gmail.com>; pqc-forum
> <pqc-...@list.nist.gov>
> *Subject:* [EXTERNAL] RE: [pqc-forum] FIPS 203 ipd v2?
> I certainly hope they won’t do a second draft. Some of us are waiting
> with bated breath for FIPS 203 – another draft and comment period would
> delay things by at least half a year… From: pqc-forum@ list. nist. gov
> <pqc-forum@ list. nist. gov>
>
> I certainly hope they won’t do a second draft. Some of us are waiting
> with bated breath for FIPS 203 – another draft and comment period would
> delay things by at least half a year…
>
> <pqc-...@list.nist.gov <mailto:pqc-...@list.nist.gov>> *On Behalf Of
> *Deirdre Connolly
> *Sent:* Thursday, April 11, 2024 11:40 AM
> *To:* pqc-forum <pqc-...@list.nist.gov <mailto:pqc-...@list.nist.gov>>
> *Subject:* [pqc-forum] FIPS 203 ipd v2?
> We were informed of several changes planned from the FIPS 203 initial
> public draft at the NIST PQC Conference today, is there going to be a
> second draft to look at for those? I'm especially interested in the
> updated APIs (high-level that source randomness that call low-level that
> don't) and how the key seeds may be used.
>
> Thanks!
> Deirdre
>
> --
> You received this message because you are subscribed to the Google
> Groups "pqc-forum" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pqc-forum+...@list.nist.gov
> --
> You received this message because you are subscribed to the Google
> Groups "pqc-forum" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pqc-forum+...@list.nist.gov
> --
> You received this message because you are subscribed to the Google
> Groups "pqc-forum" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pqc-forum+...@list.nist.gov
Paul Hoffman
>
> We were informed of several changes planned from the FIPS 203 initial public draft at the NIST PQC Conference today, is there going to be a second draft to look at for those? I'm especially interested in the updated APIs (high-level that source randomness that call low-level that don't) and how the key seeds may be used.
- Small last-minute changes to specifications can sometimes make things worse.
- Updating deployed cryptography for what some people term as "minor fixes" always leads to widespread deployment of incompatible versions because some people won't update unless it is "major".
- Unreviewed specs reduce the trust in the NIST processes.
In the case of MK-KEM, there is an additional problem, namely that one of known patents requires the implementation of exactly what NIST specifies, so if problems are found later due to insufficient review, an implementer cannot update to a safer version without possibly incurring patent liability.
--Paul Hoffman
Deirdre Connolly
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/6643e6b7-ef48-47af-a1c7-f063a7dc9985n%40list.nist.gov.
Mike Ounsworth
Thanks Deirdre.
> Basically the API changes to support a high level that sources randomness and a low level that accepts randomness, plus the key format changes that support storing keys as seeds, may address all of the binding properties concerns we've been looking at.
Right, call me skeptical, but that’s not a straight-line from those API changes, to solving the MAL security game issues. This seems like the kind of thing where careful analysis in 6 – 12 months will find that the first attempt a this does not actually achieve its stated security goals, and then we’ll be in exactly the situation Paul described where we are trying to make breaking security changes to a published FIPS document.
“Do it fast” vs “do it right”.
It seems to me like “do it right” – ie solving the MAL security game issues within the ML-KEM primitive – requires another full round of public review.
Whereas “do it fast” would be to say that ML-KEM does not attempt to provide this security property, and if you want it then bind PK and CT at the protocol layer. As I understand the issues with the MAL security game and ML-KEM, we don’t _need_ to solve this within the ML-KEM primitive, we _can_ solve it at the protocol layer. As I understand it, it’s effectively trading faster publication of FIPS 03 for protocol performance and complexity, and pushing the problem up the pyramid where every crypto protocol needs to accommodate it instead of solving it once in ML-KEM; trading elegance against further delays to FIPS 203.
Is that sortof about right?
---
Mike Ounsworth
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAFR824wnEK5kb3XXqcDy2terueGCDv3Uzp-42mrNnW_kEuNLJw%40mail.gmail.com.
Moody, Dustin (Fed)
Sent: Thursday, April 11, 2024 12:51 PM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: Re: [pqc-forum] FIPS 203 ipd v2?
Simon Hoerder
I'm not sure whether the people want to have FIPS 203 rushed through or
whether they want to avoid further changes.
CNSA v2 and related memos from the White House have sent a lot of people
and money scrambling to meet the CNSA v2 timeline. Which does set some
ambitious targets. Other countries have similarly started to ramp up
their transition programs significantly with a lot of focus on critical
infrastructure as early adopter.
If the standards keep getting delayed, that's going to cause significant
issues within early adopter industries and their suppliers. They will
understand if a serious issue is getting fixed but there won't be a lot
of patience for changes that look like adding features.
So my stance is that all (further) changes should be very carefully
evaluated whether they're important enough to cause further delays and
in the meantime NIST should do everything possible to support developers
in mitigating delays. That does not preclude public reviews or an ipd v2
but may well limit the scope of what comments will be accepted.
Deirdre, thanks for sharing the pictures. Much appreciated!
Best,
Simon
John Mattsson
Dustin Moody wrote:
We do NOT plan to have another draft for any of ML-KEM, ML-DSA, or SLH-DSA.
I strongly agree with not having a formal second draft version and a formal comment period. That would delay publication severely. I like many other on this list want final versions quite soon.
But as Deirdre writes there are quite a lot of planned changes, and more have been added since Deirdre started this thread. Couldn’t NIST informally share the currect work-in-progress drafts in an informal way? E.g., by just posting them on this list or regularly posting work-in-progress drafts to GitHub?
Cheers,
John Preuß Mattsson
From:
pqc-...@list.nist.gov <pqc-...@list.nist.gov> on behalf of Simon Hoerder <si...@hoerder.net>
Date: Thursday, 11 April 2024 at 19:51
To: pqc-...@list.nist.gov <pqc-...@list.nist.gov>
Subject: Re: [Ext] [pqc-forum] FIPS 203 ipd v2?
[You don't often get email from si...@hoerder.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.