Align PKESK v3 ciphertext format with crypto-refresh's X25519 and X448

[dkg]

In §5.1.6 of the crypto-refresh, the order of fields in the ciphertext object is:

• 32 octets representing an ephemeral X25519 public key.
• A one-octet size of the following fields.
• The one-octet algorithm identifier, if it was passed (in the case of a v3 PKESK packet).
• The encrypted session key.

This change aligns the PQC wire format with the crypto-refresh wire format by swapping the length octet with the optional v3 PKESK algorithm identifier.

This has no impact on the v6 PKESK wire format, since the algorithm identifier field isn't present.

It is easier for implementers if they don't have to tweak these things between algorithms.

[falko-strenzke]

In my view, what the crypto-refresh does here does not make much sense. The size field is clearly there for the wrapped session key (isn't it?). Why then group the algorithm ID together with the wrapped session key?

Yet I am not opposed to aligning with the crypto refresh here, but first I would like to hear what others have to say to this.

[dkg]

I'm not sure what's "logical" about either way. if we want to argue logic, we can just say "until the end of the packet" and then we don't need a length octet at all. i believe the idea is that it's just there for "safety" purposes, or for ease in parsing. If we're going to make it for ease in parsing, it really should not diverge from other packets which have the same behavior.

[falko-strenzke]

@wussler What do you think?

[dkg]

fwiw, with the size octet before the algorithm ID octet, you can tell whether the extra algorithm ID octet is supposed to be there based on whether the size octet mod 8 is congruent to 1. with the other way around, you can't tell from the contents of the packet whether that's the case.

Whether that's a smart way to parse such a packet is a separate question, i guess -- you'd like that to align with the version number explicitly more than anything else.

[falko-strenzke]

fwiw, with the size octet before the algorithm ID octet, you can tell whether the extra algorithm ID octet is supposed to be there based on whether the size octet mod 8 is congruent to 1. with the other way around, you can't tell from the contents of the packet whether that's the case.

Understood, its trivial math. But to me it still makes, at least per se, no sense to put a length field which says "this is the length of the next two subsequent fields. Use the following formulas to calculate the lengths of the individual fields ...". That is not how protocol specs are usually built. But as I wrote, I also see the argument of aligning with the c-r and will not argue against it. But I first want to hear Aron's opinion, him being an actual stakeholder and having the experience (among the editors, I mean).