Re: quic and compatibility with cryptographic implementations

[Dimitri John Ledkov <[e-mail]>]

On Sun, 26 Apr 2026 at 10:02, Martin Thomson <[e-mail]> wrote:
>
> On Sun, Apr 26, 2026, at 11:01, Dimitri John Ledkov wrote:
> > 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.
>
> While you can ask people to make a value longer than 112 bits, the RFC only requires 64 bits, so those that are not updated might not meet your expectations.  So you can ask, but you will likely never cause every deployed implementation to choose 14 byte connection IDs to make your NIST FIPS requirements happy.
>
> To be clear, this is a use of the algorithms that does not need FIPS certification.  We send the keys along with the ciphertext.  Though we can't expect every FIPS audit to appreciate this not-so-fine point, the point will remain.

Right, thanks.

To have cryptographic protection of the initial packets something like
the expired "Protected QUIC Initial Packets" draft
https://datatracker.ietf.org/doc/html/draft-duke-quic-protected-initial-04
is needed.

Without that, the initial packets use cryptography for "good measure"
but not as part of approved cryptographic protection. The QUIC
cryptographic security relies on the TLSv1.3 handshake that happens
after the initial packets.

This means initial packet encryption falls under FIPS 140-3
Implementation Guidance 2.4.A which allows these non-approved
algorithms (short connection id as IKM in HKDF-Extract and
AEAD_AES_128_GCM with externally set IV) as they are either not
security relevant or redundant. Similar to how MD5 in TLSv1.0/v1.1 was
allowed by the very same implementation guidance. I will ask them to
update that guidance to call out QUIC initial packets as allowed in
approved mode. Coding wise for OpenSSL it means setting key-check
OSSL_KDF_PARAM_FIPS_KEY_CHECK param to zero
https://docs.openssl.org/3.6/man7/EVP_KDF-HKDF/#supported-parameters;
for Golang it will mean wrapping relevant code computing initial
secrets in fips140.WithoutEnforcement
https://pkg.go.dev/crypto/fips140#WithoutEnforcement.

>
> > Has it been considered to upgrade this to AEAD_AES_256_GCM by default?
>
> No.  For the same reason as above, this would not interoperate with existing clients.
>

Ack. This will remain true, until / if we have something like the
expired "Protected QUIC Initial Packets" draft
https://datatracker.ietf.org/doc/html/draft-duke-quic-protected-initial-04
published and widely deployed which seems to allow selecting
encryption type and keys for the initial packets.

-- 
Regards,

Dimitri.