Change:
To ensure that sufficient data is available for sampling, packets are padded so that the combined lengths of the encoded packet number and protected payload is at least 4 bytes longer than the sample required <del> for header protection.  For the AEAD functions defined in TLS13, which have 16-byte expansions and 16-byte header protection samples, this results in needing at least 3 bytes of frames in the unprotected payload if the packet number is encoded on a single byte, or 2 bytes of frames for a 2-byte packet number encoding. </del> <ins> for header protection.  The ciphersuites defined in TLS13 - other than TLS_AES_128_CCM_8_SHA256, for which a header protection scheme is not defined in this document - have 16-byte expansions and 16-byte header protection samples.  This results in needing at least 3 bytes of frames in the unprotected payload if the packet number is encoded on a single byte, or 2 bytes of frames for a 2-byte packet number encoding. </ins> The sampled ciphertext for a packet with a short header can be determined by the following pseudocode:

Discussion:
For input to discussion on the related issues. This says that we don't do CCM_8 and makes it clear that you don't reject an attempt to use a ciphersuite you don't understand. This is an editorial resolution to the design issue. , .
LGTM
I think I must be entirely missing the point, but I don't understand this: Can you please explain how this works? For the sake of argument, TLSAES128CCM8_SHA256 is not supported, but the peer chooses to use it, and the TLS engine behind it all decides to support it via some configuration that the endpoint is directly aware of. How does the endpoint now deal with header protection. Is it assumed that this is a TLS black box so it just magically works if the TLS engine has accepted the cipher via some useful API call. If it is a TLS blackbox API call, how would that work with HW offloading?
Now I understand it. Being offered by TLS is not the same as being used by any of the endpoints. Sorry for the noise.
Suppose that we had a future TLS cipher suite such as AESOCBSHA256. Would that work with QUIC without a new QUIC draft? The AEAD part is already clearly defined and given that AES-OCB uses AES, the same HP mechanism as we currently use with GCM can be used here. From my perspective, the desirable property is that if we add new TLS cipher suites with analogous cipher cores (block cipher and/or nonce-based stream cipher) to the existing spec, then no new QUIC document should be required. An alternative design would be to just require a "QUIC applicability" paragraph in new TLS cipher suites analogous to the DTLS-OK IANA flag. (see also ).
How about header protection which depends on being defined for the negotiated AEAD?
That's what paragraph 2 above is about.
As discussed in , we did not originally have a good way to make AEADAES128CCM8 work in QUIC, because it needs a 16 byte sample for header protection but only produces an 8 byte auth tag. However, since then we have merged , and it's therefore easy to pad short packets by 8 extra bytes when using CCM_8.

There might be QUIC use-cases that could benefit from the shorter tags, and it would be nice to have QUIC support all the original TLS 1.3 cipher suites.
+1 CCM_8 is big in environments like broadcast production
This just adds an odd error-prone special case for padding, and the key benefit of being short is lost on short packets due to padding.
I think we can accommodate this in QUIC v1. The change has zero impact on implementations not supporting CCM8. Code can be left as-is. Specification-wise the required change would be to alter the definition of minimal payload size from 4 to ).
I disagree. It's only the very short packets that do not have the benefit. Longer packets do not require additional padding, and will benefit from the use of the shorter tag.
I don't think that we need this. The reasons offered thus far amount to "because we can". I'd like to see some analysis suggesting that shorter authentication tags are OK in the general case. Or text explaining constraints on deployments that choose to use a shorter tag. I understand the benefits of CCM over GCM; I understand that this includes an ability to have a shorter tag, unlike GCM which fails badly. I understand the desire to save bits. But it isn't really that many bits, and the shorter tag changes the odds of an invalid packet being accepted fairly significantly.
NAME can you elaborate on what makes QUIC different from TLS that suggests AES128CCM_8 is useful in TLS but not in QUIC?
It's worth remembering that QUIC packet sizes are (typically) smaller than TLS record size which means that the consequences of saving bytes are larger in QUIC than in TLS.
Well, we generally discourage the use of CCM_8 in TLS as well. We mostly only added it for IoT purposes.
NAME QUIC is also applicable to IoT, CCM_8 should be supported but discouraged here as well.
Is there a strong argument to diverge from existing TLS practice here?
CCM8 is better suitet for a separate QUIC version for IoT where header protection and padding is also dropped and where the traffic volume is low. A cheaper handshake would also be needed. Someone said CCM8 is commonly used with video AFAIR.
NAME I don't think encouraging protocol fragmentation is a good idea.

The reason TLS 1.3 has CCM_8 is to allow IoT use-cases to use TLS 1.3 instead of making them develop new protocols. The same argument applies to QUIC.
Q: Should we allow it for QUIC, but not allow it for HTTP/3?
No, the application layer shouldn't deal with transport security. If the security properties changes, it should be a new QUIC version.
I agree with NAME on this one. HTTP/2 doesn't disallow CCM_8 when run over TLS 1.3.
But if I argue that CCM8 changes security properties, you might disagree since that would move CCM8 to a new QUIC version.
NAME this doesn't seem like a very persuasive analogy, given that HTTP/2 has a long list of rules about disabling ciphers that were present in TLS 1.2: URL The reason that it doesn't have that for TLS 1.3 is that (1) TLS 1.3 post-dates HTTP/2 and (2) the suites were chosen according to the same principles Second, as a practical matter, most browsers do not support CCM_8, and I suspect that will continue to be true for most stacks, partly because performance is not awesome (as it requires computing CBC). If, as NAME implies, we want to have a cipher with a shorter authentication tag (I'm undecided on this topic myself at present) for general use then we should consult CFRG for one, rather than just use the one that happened to be the one that IoT devices supported.
I would personally have preferred to include AES128CCM8 in the QUIC spec to have parity with TLS 1.3, but I can live with the text from because that allows someone to write a one-page spec on how to use AES128CCM8 in QUIC without risking interoperability issues. I'm OK with closing this issue with no further action at this point.
LGTM