Adding the QUIC WG and removing the Sec ADs. Ilari, I would like your input on the questions below.
On Wed, Nov 24, 2021 at 3:50 PM Martin Duke <[email protected]> wrote: > Hi All, > > Thanks for the review. I've made an attempt to capture this conversation > in a PR: > https://github.com/quicwg/load-balancers/pull/146 > Please take a look. > > Some questions from earlier in the thread: > (1) Is it alright if the server ID and nonce are of very different > lengths, so that the "split" is nowhere near even? Or should we just take > exactly half the octets even though they represent different information? > > (2) Does this have similar security properties to a normal block cipher > with 16 bytes of entropy? > > On Thu, Nov 18, 2021 at 2:09 PM Martin Duke <[email protected]> > wrote: > >> Ilari, >> >> One last question about the 4-pass design you describe. With these >> improvements, do you see any *security* advantages of a technique where >> we have a full-size AES block via a random nonce (i.e. 16 - sid_length >> bytes of nonce)? Clearly, it's nice to do only one pass, but if it doesn't >> confer any additional protection I think the cost in terms of longer CIDs >> is probably too prohibitive to make it a worthwhile alternative. >> >> On Thu, Nov 18, 2021 at 12:54 PM Martin Duke <[email protected]> >> wrote: >> >>> I received a PR to pad these items in accordance with RFC 2315 (PCKS #7) >>> sec 10.3, instead of zeros. Is this a valuable improvement? I have very >>> little intuition here. >>> >>> On Thu, Nov 18, 2021 at 10:38 AM Christian Huitema <[email protected]> >>> wrote: >>> >>>> Ilari, >>>> >>>> Thanks for the suggestion. This is very practical, and I will change >>>> the >>>> text to follow it. Your message also discusses the exchanges between >>>> load balancer, servers and clients, and I will let Martin respond to >>>> that. >>>> >>>> On 11/18/2021 3:09 AM, Ilari Liusvaara wrote: >>>> > One way would be (while also making splitting even): >>>> > >>>> > (l,r) <- split_even(server||nonce) >>>> > l <- l XOR truncate(AES(K,r||zeroes||1)) >>>> > r <- r XOR truncate(AES(K,l||zeroes||2)) >>>> > l <- l XOR truncate(AES(K,r||zeroes||3)) >>>> > r <- r XOR truncate(AES(K,l||zeroes||4)) >>>> > enc_cid <- l||r >>>> > >>>> > One issue with this is that if server||nonce is of odd length, >>>> > split_even would produce something with a half octet, which is a bit >>>> > annoying. >>>> >>>> As you say, a pure "split even" is a bit hard to implement, given octet >>>> boundaries. Would we lose too much strength by splitting at the octet >>>> boundary closest to the middle, such "3 bytes left, 4 bytes right"? >>>> >>>> I also considered a split_top_bottom, i.e. AND with (0xF0...) for top, >>>> with (0x0F) for bottom, but that's a bit exotic, and probably wrong in >>>> some subtle ways. I am worried about degenerate cases in which server < >>>> 16 and nonce < 16, in which case top might be all zeroes. >>>> >>>> -- Christian Huitema >>>> >>>> >>>> >>>> >>>> >>>>
