Draft: draft-ietf-quic-load-balancers

Commentary: After a lot of thinking about nonce reuse , I somewhat related text about stateless reset token key management . 
 Way back in , said that his three - pass algorithm meant that But we never really did that : the nonce is in the range 8 .. 16 octets , which is inherited from the original single - pass algorithm . asked if we could shorten the minimum nonce to 32 bits to reduce overall CID length ; if it were , we could support 2 ^ 24 servers with an 8 - byte CID ! This is compelling and we should definitely shorten the nonce to some value . But 32 bits means you need to roll over the keys for every 4 billion CIDs a server issues ; given that some QUIC implementations are quite profligate issuing CIDs , is that enough ? Even another byte would get us to a trillion CIDs while supporting up to 2 ^ 16 servers in 8 octets . On the other hand , the config agent can always pick a longer nonce length if the key lifetime is too short . This is how much we want to allow people to do something potentially dumb , so it 's a good spot for discussion . 
 I think some flexibility and discussion of the pros and cons here would be very useful . I think 32 bits is a reasonable min for our use cases , but maybe there 's a reason that would cause issues I 'm not aware of ? We are not profligate issuers of connection IDs and I think we just issue one extra one at any given point in time . 
 wrote : " This is compelling and we should definitely shorten the nonce to some value . But 32 bits means you need to roll over the keys for every 4 billion CIDs a server issues ; given that some QUIC implementations are quite profligate issuing CIDs , is that enough ? " Short answer : yes . Assume a server handles 2,048 connections per second , and allocates 16 CID per connection . That leaves 17 bits , 128 K connections , 64 K seconds , about 18 hours . Long answer : to make that really work , you need a good rollover mechanism . Something like , if the load balancer observes that one server has rolled over , it triggers rollover for all other servers in the pool . 
 Most connections need 1 or 2 CIDs , so I think the practical bounds are higher . Also , 2048 connections is n't that much , but 2048 per second is quite a bit based on my experience . 
 So I wonder if there 's an attack that continually changes the DCID it uses , which will cause some servers to issue way more CIDs than usual , thus forcing a rollover inside the normal key management cycle . Two countermeasures : servers SHOULD limit CID issuance to a sensible limit , and ( as says ) do a good rollover mechanism . 
 on a separate note , are there security implications for ( noncelen < sidlen ) ? I ca n't see any , but you would know better than I. 
 Perhaps I 'm over - thinking this , because I 'm not sure nonce re - use actually matters here . Assuming that a single server is n't using multiple server IDs , we are essentially encrypting the same plaintext over and over again . So even if the nonce is re - used , that is only amounting to the exact same CID being issued again ( modulo random bits in the server use field or where the length would go ) . While this is n't great , as long as it 's not done in the same connection , it does n't provide any useful information to the observer to correlate clients . If the observer is positioned to see all CIDs in use for the server pool , then over long time scales it may observer that two CIDs match , which for QUIC - LB means they were issued by the same server . Thanks to the config rotation bits , it can likely infer that the keys have n't rotated . But that has very little to do with correlating clients , which is the whole point of the document . A server that rolls over its connection IDs is going to have to generate new   keys , but this is a totally local operation . Am I not thinking about this correctly ? 
 Encryption performs a bijection from the space of tuples < sidlen , nonceto the space of numbers of size  . I do n't see a particular risk in having noncelen smaller or larger than sid_len . There is a risk in densely using the space of encrypted numbers . look at the decryption size . If an adversary picks a number at random , that number will decrypt to < sid = s , nonce = n. The shorter the ID , the denser your utilization of the space , the larger the likelihood that the randomly picked " s " will correspond to a valid server , and thus the adversary 's message hitting a server instead of being dropped at the LB . Same goes for the nonce , the adversary has more chances to get lucky if the space of nonces is densely used . But then , decryption will fail and the message will be ignored . So the main issue I see is that randomly creating SID might yield slightly more effective resource - consumption attacks . 
 Put another way , maybe   is wrong for QUIC - LB : 
 The attacker will not be able to directly correlate cid values and servers . Changing one bit in the nonce statistically changes half the bits in the encrypted sid+nonce . 
 Thanks , can we change to a 32 bit nonce and add some more text about the risks and trade - offs of shorter vs longer nonces ? I feel someone else might be better at the risks / trade - offs bit , but I 'll write a PR to change the value . 
 I already have one to go up on monday 
 SG , I 'll drop mine then . martinduke 
 On the issue of nonce reuse : I toyed with idea of being permissive about this , but for the record here 's why there 's a problem : At the extreme , say a server uses an independent nonce counter for each of its connections , so the encrypted bits follow a predictable pattern for CIDs 1 .. n issued over the life of the connection . First , if the plaintext bits ( first octet and server - use ) are the same , we ca n't demultiplex connections , and everyone will have everyone else 's stateless reset tokens . So at a minimum , the server has to keep the overall CID unique . But even it 's unique , if the encrypted bits follow this pattern , then a client connected to that server can identify other clients linked to that server . 
 Let 's do this . LG . The intent is to reduce the minimum nonce length for both Stream and Block ciphers , correct?LGTM
The nonce length MUST be no fewer than 8 and no more than 16 octets.
The nonce length MUST be no fewer than 4 and no more than 16 octets.
The Stream Cipher and Block Cipher algorithms need to generate
different cipher text for each generated Connection ID instance to
protect the Server ID.  To do so, at least four octets of the Block
Cipher CID and at least eight octets of the Stream Cipher CID are
reserved for a nonce that, if used only once, will result in unique
cipher text for each Connection ID.
Note also that when a server starts using a new QUIC-LB config
rotation codepoint, new CIDs might not be unique with respect to
previous configurations that occupied that codepoint, and therefore
different clients may have observed the same CID and stateless reset
token.  A straightforward method of managing stateless reset keys is
to maintain a separate key for each config rotation codepoint, and
replace each key when the configuration for that codepoint changes.
Thus, a server transitions from one config to another, it will be
able to generate correct tokens for connections using either type of
CID.
The Stream Cipher and Block Cipher algorithms need to generate
different cipher text for each 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 ID.