Change:
example, 0x7040b81b55ccf3 would split into a left_0 of 0x7040b81 and right_0 of 0xb55ccf3. <del> Encrypt left_0.  The encryption is 128-bit AES-ECB with the key provided by the configuration agent, and the plaintext argument is an expanded version of left_0 where left_0 constitutes the most significant bits, 0x01 is the least significant octet, and all other bits are zero. </del> <ins> Encrypt the result of expand_left(left_0) to obtain a ciphertext. </ins> <del> XOR the most significant bits of the ciphertext with right_0 to </del> <ins> XOR the least significant bits of the ciphertext with right_0 to </ins> form right_1. <del> Thus steps 3 and 4 can be expressed as "right_1 = right_0 ^ truncate(AES_ECB(key, expand(left_0, 0x01)) " </del> <ins> Thus steps 3 and 4 can be expressed as "right_1 = right_0 ^ truncate_right( AES_ECB(key, expand_left(left_0, 0x01)), len(right_0)) " </ins> Repeat steps 3 and 4, but use them to compute left_1 by expanding <del> and encrypting right_1 with the least significant octet as 0x02 and XOR the results with left_0. </del> <ins> and encrypting right_1 with the most significant octet as 0x02 and XOR the results with left_0. </ins> <del> "left_1 = left_0 ^ truncate(AES_ECB(key, expand(right_1), 0x02)) " </del> <ins> "left_1 = left_0 ^ truncate_left( AES_ECB(key, expand_right(right_1, 0x02)), len(left_0)) " </ins> Repeat steps 3 and 4, but use them to compute right_2 by expanding and encrypting left_1 with the least significant octet as 0x03 and XOR the results with right_1. <del> "right_2 = right_1 ^ truncate(AES_ECB(key, expand(left_1, 0x03)) " </del> <ins> "right_2 = right_1 ^ truncate_right( AES_ECB(key, expand_left(left_1, 0x03)), len(right_1)) " </ins> Repeat steps 3 and 4, but use them to compute left_2 by expanding <del> and encrypting right_2 with the least significant octet as 0x04 and XOR the results with left_1. </del> <ins> and encrypting right_2 with the most significant octet as 0x04 and XOR the results with left_1. </ins> <del> "left_2 = left_1 ^ truncate(AES_ECB(key, expand(right_2), 0x04)) " </del> <ins> "left_2 = left_1 ^ truncate_left( AES_ECB(key, expand_right(right_2, 0x04)), len(left_1)) " </ins> The server concatenates left_2 with right_2 to form the ciphertext CID, which it appends to the first octet.

Discussion:
narrows single-pass encryption to a special-case optimization, and simplifies presentation of the design.
There's a lot of needless bitshifting in the current algorithm. When reading from the right, each byte has to be shifted 4 bits and ORed with the neighboring byte, as currently written. There's an easier way. When encrypting side X (= { left, right }) and XORing with side Y. Set Y to zero. Set the index value (= 1..4) in the furthest byte that has been zeroed. Encrypt to get ciphertext XOR Y with the bits in the same position as Y.
There has quietly been some work on tightening up the QUIC-LB specification. At the moment, we are still short on implementations but I am hearing something might happen soon. Anyway, Christian Huitema has made substantial contributions to the security properties of Stream Cipher CID, which allows smallish CIDs, by making it a three-pass algorithm. We still have the "Block Cipher CID option" which requires CIDs of at least 17 bytes; AFAICT the only advantage at this point is that it can be decoded with 1 block encryption operation instead of three. In principle, QUIC-LB load balancers can be run with no per-connection state, in which case this would be a per-packet operation. I strongly suspect that real LBs will keep some per-4tuple state, as they do today; if so, this crypto operation only needs to occur once per packet where the 4-tuple is new. If so, the CPU impact is vanishingly small except in a storm of garbage packets. So AFAICT, the use case for Block Cipher is as follows: Willing to run one crypto operation per packet/new 4-tuple Not OK with doing three crypto operations satisfied with 17B + CIDs I strongly suspect this does not describe a real implementer, and am inclined to simply delete this in my effort to simplify the design. Nevertheless, I'm taking this to the list in case someone thinks this is an important use case.
I am pretty confident about the properties of the stream cipher, but I am not a cryptographer Should we ask a review from the CFRG?
I implemented block cipher cid in my proxy server.

It is a bit sad to hear that it is going to be removed from the spec, but I have no strong opinion to against that. If it is removed I'll just remove the reference to quic lb spec and call it our own. The good thing of block cipher cid is that its implementation is quite easy. 17 bytes cid has good entropy for random bits to manage several cid per connection.
NAME It's not gone yet! At the very least, we're going to do the crypto review.
FWIW, h2o also uses 17-byte CID backed by AES-ECB. Our server-id is 64-bit. While that might sound a bit large, it is good to have some additional space that can be used for detecting broken packets carrying bogus CIDs. Also, we do not retain 4-tuple state for each connection, because we do not want to retain connection state for all the server cluster. Instead, we decrypt CID of each packet. Our format is different from what is in QUIC-LB (our design predates the first revision of the draft), so we do not mind support for block ciphers getting removed from the document. I'm just pointing out that there are use cases where block ciphers are sufficient.
NAME thanks for the field report. While you're not conforming to the standard today, I hope you'll consider h2o servers eventually supporting the standard (at last optionally) so they can be used with migration with commodity load balancers. Would the lack of a block cipher make a meaningful difference in your willingness to do so?
if you've implemented this, please join the #quic-lb channel and we should do interop once the spec settles down
NAME Implementing the Stream Cipher CID algorithm is easy for the backend servers. IMO the practical concerns are related to load balancers. Each of the three-pass AES-ECB operation has dependency on earlier passes. That means that it is impossible to run these passes in parallel. My napkin calculation tells me that the CPU cycles required for running Stream Cipher CID algorithm on each full-sized packet would cost like 30% of decrypting a full-sized packet. There would be at least two ways to mitigate this problem. One is process multiple packets in parallel. The other is cache information, as you've suggested in this issue.

If the load balancer developers are happy to accept this complexity (for saving few bytes of CID), then I do not think I have a reason to argue against.
Please don't make decisions now about the cost of three passes. The CFRG review might very well ask us to increase the number of passes, especially if the nonce is something like a counter instead of a random number. Consider for example the usage pattern in which after a key rotation all servers in the cluster set their nonce to exactly 1. In effect, that means we are almost down to two passes, and that may arguably be too few. Or maybe not. Review will tell. If I look at the literature, 3 passes is the absolute minimum for achieving an acceptable level of mixing, but there are papers recommending 5, 6 or even 12 passes.
NAME thank you for the caution. Then I wonder if we need to decide the fate of block cipher CIDs, before the design of stream cipher CIDs become more stable.
I am not resolving this issue until the crypto review is complete.
It's unfortunately that routing by will meet some problems, image this scenario: The right way SHOULD be that quic-lb route all packets through CID, then the cpu cost can't be avoid, but I still approve the usage of stream cipher, from a safety point of view.
Good point, I'll consider this when I
reduced the Block CID (now "single-pass encryption") to the special case where noncelen + sidlen == 16.
Given the work in , I'm disinclined to remove this special case. Closing.
That works. The macros are clever, and you may want to explain the cleverness somewhere. It is obvious to me that you want to align "right" and "left" to an even number of bytes, adding a null nibble at the left or right or at the right of left. That will indeed save a lot of bit twiddling. Found an unrelated typo.