Sorry for the late response; I was going through old emails and came across this; I thought it warranted a response
> -----Original Message----- > From: TLS <tls-boun...@ietf.org> On Behalf Of Ilari Liusvaara > Sent: Saturday, April 30, 2022 5:05 AM > To: TLS@ietf.org > Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design > > I don't think compression method like ECH uses would work here. > > However, I did come up with compression method: > > 1) Sub-shares in CH may be be just replaced by a group id (two octets). > The replacements can be deduced from length of the whole share. > 2) First sub-share copies from first octets of share for the designated > group. > 3) Second sub-share copies from last octets of share for the designated > group. > > This can be decoded regardless of if the sever knows what the referenced > groups are. The compression can also never run into loop, as recursive > references are not allowed. > > > So for example, if one wants to send x25519, p256, x25519+saber and > p256+saber, one can do that as: > > - x25519: <x25519 share> (32+4 octets) > - p256: <p256 share> (65+4 octets) > - x25519+saber: <x25519 id><saber share> (2+992+4 octets) > - p256+saber: <p256 id><x25519+saber id> (2+2+4 octets) > > Total overhead is 22 octets. 16 for 4 groups, and 6 for the compression > itself. That sort of thing is possible. However, it was my understanding that the working group wanted a simple proposal; one with minimal changes to the TLS architecture. The current draft, which treats the hybrid as a single atomic group, meets that. This compression protocol would require something on the server side to parse through the compressed key shares to extract the desired shares (and, of course, handle it if the shares were not present). We'd also need something to distinguish between exactly one key share was presented (that is, the current protocol) and when multiple key shares were given. And, for consistency, we'd have the server use the same TLV format for its hybrid keyshares if it selects a hybrid group. So, the advantage of this compressed design is if the client's proposal was close (e.g. it wanted to negotiate either P256+Kyber or x25519+Kyber), it wouldn't have to guess - it could include all the alternatives, and as long as the server accepted either one, the negotiation would proceed; with the current draft design, the client would have to guess (and if it guessed wrong, we'd take an additional round trip for the HRR). The disadvantage of this design is a bit of additional complexity. Does the working group have a strong opinion about this? > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
