Hi, NIST SP 800-131r2 https://csrc.nist.gov/pubs/sp/800/131/a/r2/final specifies in section 8 Deriving Additional Keys from a Cryptographic Key, that "The length of the key-derivation key shall be at least 112 bits." And many cryptographic modules that implement this standard enforce this by default on the IKM of the HKDF-Extract(salt, IKM) -> PRK; and often provide a separate API to relax this enforcement; which often might be used.
Which is input keying material (IKM) of the Destination Connection ID field in quic RFC 9001 section 5.2 https://www.rfc-editor.org/rfc/rfc9001#section-5.2. Would it help with interoperability with such strict cryptographic libraries if the destination connection ID had a recommended minimum length of 112 bits? Note doing so is compatible with the current RFC wording as is, without needing a new version and a new salt value. I am observing non-fips clients failing to establish connectivity with fips servers, based on the client chosen connection ID - getting unlucky. I understand that the initial secrets are not authenticated, but cryptographic modules often do not know the intent. Potentially it is also worth asking the cryptographic modules to allow such calculations with the known quic salt values. In 5.4.1 it states that "Separately in Prior to TLS selecting a cipher suite, AES header protection is used (Section 5.4.3), matching the AEAD_AES_128_GCM packet protection" some modules prefer to use AEAD_AES_256_GCM instead, and AEAD_AES_128_GCM can sometimes be unavailable by policy (or requires custom API calls to turn back on). Has it been considered to upgrade this to AEAD_AES_256_GCM by default? -- Regards, Dimitri.
