forbid use of cipher suites with nonce shorter than 12 bytes?

[kazuho]

In multipath QUIC, we encode CID sequence and packet number as a 12-byte nonce.

That works well in practice; to my knowledge, AEAD cipher-suites tend to have N_MIN of at least 12 bytes.

However, I'm concerned that that is not a requirement in RFC 8446 or RFC 9002.

To me it seems that Section 5.3 of RFC 8446 that AEAD with N_MIN below 8 bytes MUST NOT be used with TLS/1.3, which is also sufficient for QUIC v1.

As Multipath QUIC requires N_MIN of at least 12-bytes, I think we should explicitly ban use of AEAD cipher suites with N_MIN less than 12 bytes.

[yfmascgy]

That's a good point. I checked that:

TLS_AES_128_GCM_SHA256 uses a 12-byte nonce. TLS_AES_256_GCM_SHA384 also uses a 12-byte nonce. TLS_CHACHA20_POLY1305_SHA256 uses a 12-byte nonce. TLS_AES_128_CCM_SHA256 uses an 8-byte nonce. TLS_AES_128_CCM_8_SHA256 uses an 8-byte nonce.

So I think we should require the use of an AEAD cipher suite with nonce greater or equal to 12-bytes when enable_multipath is negotiated. Otherwise, we have a TRANSPORT_PARAMETER_ERROR.

[kazuho]

@yfmascgy I think TLS_AES_128_CCM_SHA256 is defined by RFC 5116 with N_MIN and N_MAX of 12 bytes, so it would be fine to use it in multipath QUIC.

TLS_AES_128_CCM_8_SHA256 is forbidden in QUIC (because an 8-byte AEAD tag is insufficient for header protection (RFC 9002 section 5.3). But its N_MIN and N_MAX are also 12 bytes.

This issue is addressing the theoretical possibility of QUIC v1 adding a cipher suite with a shorter nonce.