Original text:
connection, it is a sufficient means of avoiding an Oracle without additional measures.  11. There are no IANA requirements.

Reviewer comments:
NAME please take a look.
Thanks Christian, this looks great.
NAME has done some nice analysis on the constraints of using a 96-bit random nonce to encrypt the Shared-state retry keys. This analysis should be in security considerations.
I did a nice analysis? I am collecting here the relevant comments on PR : 1- (by NAME ) Birthday paradox says with a 64 bit random field you will expect collisions after 2^32 tokens -- and that you have to change the key sooner than that if you want to minimize the risk. If you want the risk of collision below 10E-5 (five nines...) then you should not use the key more than 19 million times. It should be technically possible to make the identifier 12 bytes long -- that's the normal size of the IV for AES GCM. The same reasoning says that the key should not be use more that 4.0 E+14 times -- 400 trillion times. That may be the way to go. Better than trying to squeeze an 18 bytes ID there. Or we would have to use something a bit more exotic than AES GCM, but I would rather not go there. 2- (by NAME ) I think we have five options: (1) A 96-bit random number for the sequence number, and just assume there are no collisions (you've computed the very low probability) -- this is wire inefficient but very easy (2) For the shared-state case, the service simply forwards packets with server-generated tokens rather than trying to validate them. Therefore this format is only generated by the retry service and it can use all the sequence numbers without fear of collision. -- this is very easy and wire-efficient, but slightly reduces the usefulness of the Retry Service. 3- (by NAME we only have the following 2 options: (1) A 96-bit random number for the sequence number, and just assume there are no collisions (you've computed the very low probability) -- this is wire inefficient but very easy. (3c) Assign each server a shorter ID for Retry purposes, and put in the token: medium token size, but involves the most configuration. For AEAD, compose the 96 bit sequence as "(up to) 32 bit server ID" + "(up to) 64 bit server-chosen token ID". The advantage of (3c) over (1) it potentially reduced transmission overhead. For example, the server ID might well be just 16 bits, the token ID might be just 32 bits. If we have a server ID, the LB can use it to direct the incoming Initial to the server that allocated the token, which may or may not be useful. The drawback of (3c) is more configuration, and also exposing the server ID in cleartext. If server ID privacy is an issue, we need something like header protection as part of the token protection. After discussion, we realized that the "96 random bits" option was preferable overall, because: 1) It does not require managing short "configuration identifiers" in complement to server ID; 2) It does create some configuration overhead, but that's limited to at most 4 bytes per token, thus manageable; 3) Birthday paradox tells us that the first collision has a 50% chance of happening after 2^48 tokens have been allocated, which is a fairly large number in practice. We will want to rotate the token encryption key sooner than that.
Or do you want to compare AES-GCM to other solutions, such as AES-ECB? ECB encryption has a predictability issue, which is demonstrated for example by the penguin picture in . That weakness can expose repetitive patterns in 16-bytes chunks of the token, server-id for example.
AEAD encryption also has the advantage of immediate detection of forged tokens.
But there is one weakness in the "96 bit random" proposal. It requires that the generators actually use a crypto grade random number generator.
I was referring to the specific bit about how long it is safe to use a given key because we have 96 bits of entropy. Not the rest.
Oh, that. We should ask CFRG, but the conservative behavior would be to follow the guidelines in QUIC-TLS section 6.6: "For AEADAES128GCM and AEADAES256GCM, the confidentiality limit is 2^23 encrypted packets; see Appendix B.1. For AEADCHACHA20POLY1305, the confidentiality limit is greater than the number of possible packets (2^62) and so can be disregarded. For AEADAES128_CCM, the confidentiality limit is 2^21.5 encrypted packets; see Appendix B.2. Applying a limit reduces the probability that an attacker can distinguish the AEAD in use from a random permutation; see [AEBounds], [ROBUST], and [GCM-MU]." So, basically, 8 million tickets.
But the CFRG computations assume messages that are 10K long. Tickets would typically be 1/100th of that, that may well make a difference. Or maybe it doesn't. Got to ask.
The 96 bits make a difference with 64 bits in the risk of collisions. If there are 2^32 tickets issued with the same key, the chances of at least one collision with 64 bit unique number is 50%; with 96 bits, it is about 1.1E-10. Even if there are only 2^26 tickets issued with that key, the chances of at least one collision with 64 bit unique number is still 0.016%, which many will find too high for comfort.
Do you feel comfortable writing a paragraph about this in the Security Considerations?

Revised text:
connection, it is a sufficient means of avoiding an Oracle without additional measures. <ins> 10.6. The Shared-State Retry Service defined in shared-state-retry describes the format of retry tokens or new tokens protected and encrypted using AES128-GCM.  Each token includes a 96 bit randomly generated unique token number, and an 8 bit identifier of the AES-GCM encryption key.  There are three important security considerations for these tokens: An attacker that obtains a copy of the encryption key will be able to decrypt and forge tokens. Attackers may be able to retrieve the key if they capture a sufficently large number of retry tokens encrypted with a given key. Confidentiality of the token data will fail if separate tokens reuse the same 96 bit unique token number and the same key. To protect against disclosure of keys to attackers, service and servers MUST ensure that the keys are stored securely.  To limit the consequences of potential exposures, the time to live of any given key should be limited. Section 6.6 of QUIC-TLS states that "Endpoints MUST count the number of encrypted packets for each set of keys.  If the total number of encrypted packets with the same key exceeds the confidentiality limit for the selected AEAD, the endpoint MUST stop using those keys."  It goes on with the specific limit: "For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit is 2^23 encrypted packets; see Appendix B.1."  It is prudent to adopt the same limit here, and configure the service in such a way that no more than 2^23 tokens are generated with the same key. In order to protect against collisions, the 96 bit unique token numbers should be generated using a cryptographically secure pseudorandom number generator (CSPRNG), as specified in Appendix C.1 of the TLS 1.3 specificationRFC8446.  With proper random numbers, if fewer than 2^40 tokens are generated with a single key, the risk of collisions is lower than 0.001%. </ins> 11. There are no IANA requirements.