Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-97763

*P:Q/*class:ics - use new openssl group selection syntax in crypto-policies

Linking RHIVOS CVEs to...Migration: Automation ...Sync from "Extern...XMLWordPrintable

    • crypto-policies-20250714-1.git95bf40e.el10
    • No
    • Low
    • 2
    • rhel-security-crypto-spades
    • 20
    • 27
    • 2
    • False
    • False
    • Hide

      None

      Show
      None
    • Yes
    • Crypto25August, Crypto25September
    • Hide

      AC) No policy we ship places more than 4 asterisks in group selection

      AC) No policy we ship places more than 1 slash in group selection

      AC) For each of LEGACY:PQ, DEFAULT:PQ, FUTURE:PQ and FIPS:PQ openssl client sends two key shares:

      • one for the highest priority PQ group (SecP256r1MLKEM for FIPS, X25519MLKEM768 otherwise),
      • one for the highest priority classic group (SECP256R1 for FIPS, X25519 otherwise)

      AC) When key_share includes classic groups and no PQ groups supported by the openssl server, but there's an overlap for PQ groups between the client and the server, openssl server goes through a HRR to request a PQ group (e.g. a server in FIPS mode that receives key shares for X25519MLKEM768 and P-256 with groups that also include Secp256r1MLKEM768 in FIPS mode should negotiate Secp256r1MLKEM768 through HRR)

      AC) For a policy with classic and PQ algorithms interleaved in group, openssl config lists PQ ones before the slash and classic ones after a slash, while maintaining the relative priority of them both within the classic and the PQ group class the leftmost group in every list with a slash is prefixed with an asterisk for a policy with just the classic algorithms in group, there is no slash for a policy with just the PQ algorithms in group, there is no slash.

      Show
      AC) No policy we ship places more than 4 asterisks in group selection AC) No policy we ship places more than 1 slash in group selection AC) For each of LEGACY:PQ, DEFAULT:PQ, FUTURE:PQ and FIPS:PQ openssl client sends two key shares: one for the highest priority PQ group (SecP256r1MLKEM for FIPS, X25519MLKEM768 otherwise), one for the highest priority classic group (SECP256R1 for FIPS, X25519 otherwise) AC) When key_share includes classic groups and no PQ groups supported by the openssl server, but there's an overlap for PQ groups between the client and the server, openssl server goes through a HRR to request a PQ group (e.g. a server in FIPS mode that receives key shares for X25519MLKEM768 and P-256 with groups that also include Secp256r1MLKEM768 in FIPS mode should negotiate Secp256r1MLKEM768 through HRR) AC) For a policy with classic and PQ algorithms interleaved in group, openssl config lists PQ ones before the slash and classic ones after a slash, while maintaining the relative priority of them both within the classic and the PQ group class the leftmost group in every list with a slash is prefixed with an asterisk for a policy with just the classic algorithms in group, there is no slash for a policy with just the PQ algorithms in group, there is no slash.
    • Pass
    • Enabled
    • Automated
    • Enhancement
    • Hide
      Feature, enhancement: openssl servers will automatically prioritize PQ groups over classic groups. openssl clients will pre-generate and send a key_share for one highest priority PQ group and one highest priority classic group
      Reason: to ensure the best interoperability between PQ and non-PQ servers and clients while preferring hybrid PQ groups over classic groups for their superior cryptographic properties
      Result: the order of the groups specified in the cryptographic policy will only become respected to a certain extent and all enabled PQ groups, if any, will take priority over all classic ones. the order of the groups within each of the two categories will still be taken into account by openssl. the old behaviour can only be restored by disabling all PQ groups
      Show
      Feature, enhancement: openssl servers will automatically prioritize PQ groups over classic groups. openssl clients will pre-generate and send a key_share for one highest priority PQ group and one highest priority classic group Reason: to ensure the best interoperability between PQ and non-PQ servers and clients while preferring hybrid PQ groups over classic groups for their superior cryptographic properties Result: the order of the groups specified in the cryptographic policy will only become respected to a certain extent and all enabled PQ groups, if any, will take priority over all classic ones. the order of the groups within each of the two categories will still be taken into account by openssl. the old behaviour can only be restored by disabling all PQ groups
    • Proposed
    • Unspecified
    • Unspecified
    • Unspecified
    • None

      OpenSSL 3.5 features new syntax for group selection, asterisks and slashes:

      • asterisks before group names signify that the client must send key_share for this group
        (note, no more than 4 asterisks are allowed at the same time, or openssl starts ignoring you)
      • slashes subdividing the group list signify that the server must only resort to using the groups from the next slashed group subdivision if none of the groups from the previous one are supported by the client

      We should use this functionality to support the following sane default we're after:

      • divide the groups into post-quantum (hybrid, pure) and classical ones, with the post-quantum ones given priority over the classic ones because they provide new security properties
      • "star" the leftmost post-quantum and the leftmost classic group for HRR-less negotiation with the most common servers out there

      We plan to seek out this default behaviour for other libraries as well, no matter whether configured through crypto-policies or implemented as a library default.

      Compare and contrast https://issues.redhat.com/browse/RHEL-91144: here we introduce no additional configurability, at least for now.

              asosedki@redhat.com Alexander Sosedkin
              asosedki@redhat.com Alexander Sosedkin
              Alexander Sosedkin Alexander Sosedkin
              Ondrej Moris Ondrej Moris
              Mirek Jahoda Mirek Jahoda
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated: