Original text:
(i.e., the nonce is at least as large as the server ID).  If the server ID is longer, a fourth pass is necessary: <del> "right_0 = right_1 ^ truncate_right(AES_ECB(key, expand_left(left_0, 1 + cid_len))) " </del>  and the load balancer has to concatenate left_0 and right_0 to obtain the complete server ID. have each other's stateless reset token unless that key has changed in the interim. <del> The encrypte mode needs to generate different cipher text for each </del>  generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the CID are reserved for a nonce that, if used only once, will result in unique cipher text for each Connection therefore compare the expected rate at which servers will generate CIDs with the lifetime of a configuration.  9. There are no IANA requirements.

Reviewer comments:
Discuss Distinguishing Attack in security section. Fix specification of Four Passes decryption Fix number of kramdown issues.
NAME I think this simple PR is ready.
Thank you, this is perfect.
We're awaiting more data to fully understand this, but we may need to allow 4, 6, or 12 passes as configuration options.
Fixed by , but we're instead going to go with in lieu of doing this.
The analysis in the second crypto review should be in the security considerations.
I believe there is an edge case where a partially chosen plaintext is possible. 1) The load balancer is supporting both an encrypted and unencrypted config, on different codepoints, that happen to use the same server ID mapping 2) The server is generating encrypted CIDs. 3) The attacker sends an initial packet sends an unencrypted CID. 4) Any server generated CID is therefore using the unencrypted server ID as plaintext. The random nonce should generally protect us, but maybe not? Anyway, security considerations could say something like "unencrypted and encrypted CIDs MUST NOT use the same server ID assignments because...".
Fixed by

Revised text:
(i.e., the nonce is at least as large as the server ID).  If the server ID is longer, a fourth pass is necessary:  <ins> "right_0 = right_1 ^ truncate_right( AES_ECB(key, expand_left(left_0, cid_len, 1), len(right_1)) " </ins> and the load balancer has to concatenate left_0 and right_0 to obtain the complete server ID. have each other's stateless reset token unless that key has changed in the interim.  <ins> The encrypted mode needs to generate different cipher text for each </ins> generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the CID are reserved for a nonce that, if used only once, will result in unique cipher text for each Connection therefore compare the expected rate at which servers will generate CIDs with the lifetime of a configuration. <ins> 8.7. The Four Pass Encryption algorithm is structured as a 4-round Feistel network with non-bijective round function.  As such, it does not offer a very high security level against distinguishing attacks, as explained in Patarin2008.  Attackers can mount these attacks if they are in possession of O(SQRT(len/2)) pairs of ciphertext and known corresponding plain text, where "len" is the sum of the lengths of the Server ID and the Nonce. The authors considered increasing the number of passes from 4 to 12, which would definitely block these attacks.  However, this would require 12 round of AES decryption by load balancers accessing the CID, a cost deemed prohibitive in the planned deployments. The attacks described in Patarin2008 rely on known plain text.  In a normal deployment, the plain text is only known by the server that generates the ID and by the load balancer that decrypts the content of the CID.  Attackers would have to compensate by guesses about the allocation of server identifiers or the generation of nonces.  The these attacks are thus mitigated by making nonces hard to guess, as specified in cid-entropy, and by rules related to mixed deployments that use both clear text CID and encrypted CID, for example when transitioning from clear text to encryption.  Such deployments MUST use different server ID allocations for the clear text and the encrypted versions. These attacks cannot be mounted against the Single Pass Encryption algorithm. </ins> 9. There are no IANA requirements.