Draft: draft-ietf-quic-load-balancers

Commentary: Alright I 've incorporated feedback from both of you and the one crypto review we 've received . I suggest you read all of section 5.2 ( # # Encrypted Short CID Algorithm ) to see what I 've done , as this is a total rewrite . 
 Looks good .
The nonce length MUST be no fewer than 4 octets.
Pass 1: The load balancer decrypts the server ID using 128-bit AES
Electronic Codebook (ECB) mode, much like QUIC header protection.
The encrypted nonce octets are zero-padded to 16 octets.  AES-ECB
encrypts this encrypted nonce using its key to generate a mask
which it applies to the encrypted server id.  This provides an
intermediate value of the server ID, referred to as server-id
intermediate.
Pass 2: The load balancer decrypts the nonce octets using 128-bit
AES ECB mode, using the server-id intermediate as "nonce" for this
pass.  The server-id intermediate octets are zero-padded to 16
octets.  AES-ECB encrypts this padded server-id intermediate using
its key to generate a mask which it applies to the encrypted
nonce.  This provides the decrypted nonce value.
Pass 3: The load balancer decrypts the server ID using 128-bit AES
ECB mode.  The nonce octets are zero-padded to 16 octets.  AES-ECB
encrypts this nonce using its key to generate a mask which it
applies to the intermediate server id.  This provides the
decrypted server ID.
For example, if the nonce length is 10 octets and the server ID
length is 2 octets, the connection ID can be as small as 13 octets.
The load balancer uses the the second through eleventh octets of the
connection ID for the nonce, zero-pads it to 16 octets, uses xors the
result with the twelfth and thirteenth octet.  The result is padded
with 14 octets of zeros and encrypted to obtain a mask that is xored
with the nonce octets.  Finally, the nonce octets are padded with six
octets of zeros, encrypted, and the first two octets xored with the
server ID octets to obtain the actual server ID.
This three-pass algorithm is a simplified version of the FFX
algorithm, with the property that each encrypted nonce value depends
on all server ID bits, and each encrypted server ID bit depends on
all nonce bits and all server ID bits.  This mitigates attacks
against stream ciphers in which attackers simply flip encrypted
server-ID bits.
The output of the decryption is the server ID that the load balancer
uses for routing.
The server encrypts the server ID using exactly the algorithm as
described in encrypted-short-load-balancer-actions, performing the
three passes in reverse order.
The nonce length MUST be no fewer than 4 octets.  The nonce SHOULD be
at least as long as the server ID in order to save the load balancer
an encryption pass; see below.
The server encrypts the server ID using the following four pass
algorithm, which leverages 128-bit AES Electronic Codebook (ECB)
mode, much like QUIC header protection.
In the text below, ^ is the XOR function and || is concatenation.
The truncate() function takes the most significant octets of its
argument, so that the XOR function operates on fields of the same
length.  The expand() function outputs 16 octets, with its first
argument in the most significant bits, its second argument in the
least significant bits, and zeros in all other positions.  Thus,
The example at the end of this section helps to clarify the steps
described below.
The server concatenates the server ID and nonce to create
plaintext_CID.
The server splits plaintext_CID into components left_0 and right_0
of equal length, splitting an odd octet in half if necessary.  For
example, 0x7040b81b55ccf3 would split into a left_0 of 0x7040b81
and right_0 of 0xb55ccf3.
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.
XOR the most significant bits of the ciphertext with right_0 to
form right_1.
Repeat steps 3 and 4, but use them to compute left_1 by expanding
and encrypting right_1 with the least significant octet as 0x02
and XOR the results with left_0.
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.
Repeat steps 3 and 4, but use them to compute left_2 by expanding
and encrypting right_2 with the least significant octet as 0x04
and XOR the results with left_1.
The server concatenates left_2 with right_2 to form the ciphertext
CID, which it appends to the first octet.
The following example executes the steps for the provided inputs.
Note that the plaintext is of odd octet length, so the middle octet
will be split evenly left_0 and right_0.
The load balancer decrypts the nonce and the server ID using the
reverse of the algorithm above.
and the load balancer has to concatenate left_0 and right_0 to obtain
the complete server ID.
If servers simply increment the nonce by one with each generated
connection ID, then it is safe to use the existing keys until any
server's nonce counter exhausts the allocated space and rolls over to
zero.  Whether or not it implements this method, the server MUST NOT
reuse a nonce until it switches to a configuration with new keys.
If servers simply increment the nonce by one with each generated
connection ID, then it is safe to use the existing keys until any
server's nonce counter exhausts the allocated space and rolls over.
To maximize entropy, servers SHOULD start with a random nonce value,
in which case the configuration is usable until the nonce value wraps
around to zero and then reaches the initial value again.
Whether or not it implements the counter method, the server MUST NOT
reuse a nonce until it switches to a configuration with new keys.