Hi Martin, Thanks for the suggestions. Indeed, happy to incorporate changes in framing, tone, etc. to better reflect the purpose of the document.
> At a high level, I think that this would be easier if it were more clearly > framed as *recommendations*, especially when it comes to the format of key > shares and the input secret. One advantage of the macro-level design is that > the format is can be specified on a case-by-case basis. For instance, > variable-length values might be length-prefixed; fixed size values don't need > to be. That might avoid having to directly specify a single format. > > [...] > > The concatenation approach is definitely my preferred approach, but the > inconsistency between the design for key shares and secrets is curious. This > design assumes that shares are length-delimited; secrets are not. The latter > implies that the `ss` needs to be fixed length for a given algorithm (both > the PQ and classical parts), but `ct`/`pk` does not. I can guess at why, but > when you can avoid the question, then I think you should. That is, in favour > of more generic recommendations on structure. There are examples of current PQ candidates that have variable sized ct / pk: SIKE has compressed and uncompressed variants, which are mathematically interoperable and would result in the same shared secret, but trade smaller communication for more computation. To the best of my knowledge, none of the current PQ candidates have variable sized shared secrets. We did have some debate internally when preparing the draft about whether shared secrets should have length encoding or not, and in the end decided not, despite the apparent inconsistency in design. Douglas _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
