Add fixed version of the rfc9151 policy #5277
Conversation
| @@ -132,7 +132,7 @@ extern const struct s2n_security_policy security_policy_20241001_pq_mixed; | |||
| extern const struct s2n_security_policy security_policy_20250211; | |||
| extern const struct s2n_security_policy security_policy_20250414; | |||
|
|
|||
| extern const struct s2n_security_policy security_policy_rfc9151; | |||
There was a problem hiding this comment.
Wouldn't this break compatibility for customers who are currently using this policy?
I wonder if we should keep the security_policy_rfc9151 policy and create a new policy that mirrors it, rather than replacing it with security_policy_20250429 (apologies if I misunderstood the change and this is already the case).
This way, customers who want the latest RFC9151 policy can still access it, while those who need a pinned version can use security_policy_20250429
There was a problem hiding this comment.
Customers reference policies via their string identifiers, not by referencing the policy structs directly. See the "security_policy_selection" array mapping string identifiers to policy structs. The structs aren't visible to customers.
There was a problem hiding this comment.
Ah yes I see. rfc9151 will continue to exist. Thank you for clarifying!
| @@ -1356,7 +1356,8 @@ struct s2n_security_policy_selection security_policy_selection[] = { | |||
| { .version = "20240603", .security_policy = &security_policy_20240603, .ecc_extension_required = 0, .pq_kem_extension_required = 0 }, | |||
| { .version = "20250211", .security_policy = &security_policy_20250211, .ecc_extension_required = 0, .pq_kem_extension_required = 0 }, | |||
| { .version = "20250414", .security_policy = &security_policy_20250414, .ecc_extension_required = 0, .pq_kem_extension_required = 0 }, | |||
| { .version = "rfc9151", .security_policy = &security_policy_rfc9151, .ecc_extension_required = 0, .pq_kem_extension_required = 0 }, | |||
| { .version = "20250429", .security_policy = &security_policy_20250429, .ecc_extension_required = 0, .pq_kem_extension_required = 0 }, | |||
| { .version = "rfc9151", .security_policy = &security_policy_20250429, .ecc_extension_required = 0, .pq_kem_extension_required = 0 }, | |||
There was a problem hiding this comment.
Shouldn't these point to separate security policies to prevent unintended future changes from silently impacting customers who want to pin to a specific policy? What would we do if we wanted to update the rfc9151 policy without affecting customer using 20250429 policy?
There was a problem hiding this comment.
As a rule, we don't change versioned policies. Mainly that applies to the version strings, but that also means that modifying a security policy with a version is a red flag. If you wanted to do that, you'd need to verify it wasn't mapped to a version string.
If we wanted to update the "rfc9151" policy without affecting customers, we'd point that version string at a new, updated security policy.
| @@ -66,7 +66,7 @@ For previous defaults, see the "Default Policy History" section below. | |||
| "default_fips" does not currently support TLS1.3. If you need a policy that supports both FIPS and TLS1.3, choose "20230317". We plan to add TLS1.3 support to both "default" and "default_fips" in the future. | |||
|
|
|||
| "rfc9151" is derived from [Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3](https://datatracker.ietf.org/doc/html/rfc9151). This policy restricts the algorithms allowed for signatures on certificates in the certificate chain to RSA or ECDSA with sha384, which may require you to update your certificates. | |||
| Like the default policies, this policy may also change if the source RFC definition changes. | |||
| Like the default policies, this policy may also change if the source RFC definition changes. The "20250429" policy is the current fixed policy corresponding to "rfc9151". | |||
There was a problem hiding this comment.
Can we add a comment somewhere in policy definition so that if we ever need to update the rfc9151 policy we make sure to also update which numbered policy it corresponds to in this doc?
This avoids any future changes rolling out silently for customers who want to pin to a particular policy.
Mark-Simulacrum
force-pushed
the
versioned-rfc9151
branch
from
3475d6c to
27c21cd
Compare
Release Summary:
Resolved issues:
n/a
Description of changes:
This avoids any future changes rolling out silently for customers who want to pin to a particular policy.
Call-outs:
I updated the rfc9151 components in-place (I think they're not in public APIs at all?).
Testing:
I didn't add any new tests since this is essentially just a rename of the existing policy. I don't think we have tests for every numbered policy today so that decision seems consistent (happy to add something if asked).
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.