Change:
Choose a connection identifier C_R and store it for the length of the protocol. <del> Compute the transcript hash TH_2 = H( H(message_1), data_2 ) where H() is the hash function in the selected cipher suite.  The </del> <ins> Compute the transcript hash TH_2 = H( H(message_1), G_Y, C_R ) where H() is the hash function in the selected cipher suite.  The </ins> transcript hash TH_2 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence.  Note that H(message_1) can be computed and cached already in the processing of message_1.

Discussion:
message2 could be made 44 bytes by using the known length of SIGNATUREORMAC2
I suggest to have CR as the last element of the CBOR sequence (which shouldn't be a problem and still allows for a sequential sequence parsing), i.e.: When using CoAP (or other transports with the same correlation properties), this would preserve a current good pattern as useful for message recognition: if a response transporting an EDHOC message starts with a CBOR integer, then it's an EDHOC error message. It would be good to preserve this, hence why keeping CR at the end of the new message_2, since it can now be either a CBOR byte string or a CBOR integer.
Merging this now as there was no objection to: URL This provides a solution to the concrete issue raised in .
Mistake, I intended to merge, not close.
We need to nail down what optimizations to make in the final message format. Known lengths of byte strings can be used as discussed in the old issue tracker: URL
We should confirm the values from the rewuirement phase. If I remember correctly 45 bytes for message2 in 5-hop 6TiSCH was the strictest requirement. We can reasch that but before we optimize for that, we should confirm that the group wants to optimize for 5-hop 6TiSCH (or is 4-hop godd enough) and also double check and verify that 45 bytes is the correct number to optimize for. If I remember correctly Lorawan was a little bit less demanding than 5-hop 6TiSCH wih 48 bytes?. Every single byte can make a large difference if you suddenly have to fragment and send two frames instead of one. On the other hand there has been discusssions that is would be nice to mandate CR in message2 and to skip the bstridentifier optimization of IDCREDR.
John added a comment on an issue in the old repo which probably was intended to be on this issue: URL
Several things have been discussed regarding optimisations (or simplifications adding bytes). Message2 is the largest message and it is sent over downlink in 6TiSCH which is more constrained than uplink in 6TiSCH. Therefore only message2 is discussed below. Connection IDs - It has been discussed to make conection IDs mandatory (or default).

Given the current connection id encoding this would add 1 byte to message2 when sent in CoAP response. Note that there has also been suggested to move connection ids to a shim layer. This would not affect the total overhead, just move bytes from EDHOC to lower layers. If connection ids are kept in EHOC I think EDHOC should adopt Christians suggestion for encoding.bstridentifier - Is has been pointed out that the bstridentifier is complicated and looks like overopimization, adding complexity to spec and implementations. Christian has some excellent suggestions on how to encode the connection identifiers. Then the bstridentifier is only use to encode IDCRED containing kid. This optimisations could maybe be skipped. This would add 1 byte to message2 when certain 1 byte KIDs are used. I think this should be done unless the byte saving is very much needed.Known lengths - There are several bstr whose length is known. E.g. GY and SignatureorMAC2. Concatenating GY and CIPHERTEXT2 would save 1-2 bytes. The known length of SignatureorMAC2 is harder to use as a change would mean that the plaintext is no longer a CBOR sequance. Changing plaintext to be a CBOR SEQUENCE concatenated with the value of SignatureorMAC2 would save an additional 1-2 bytes. I don't think any of these optimizations should be done unless the byte savings are essential. The above addition/removal of optimizations needs to be discussed together with a renewed discussion of the limits in 6TiSCH. In the end it is a tradeoff between complexity and how many deployments should be supported with unfragmented message_2.
As discussed during the design team meeting, the new "6TiSCH Overhead Estimator" is available at: URL This estimator obsoletes the old Google document by updating the overhead numbers to the latest RFCs that are used in 6TiSCH, fixes an erratum present in the old doc, and adds new features such as short addressing support and UDP overhead compression.
As discussed in the recent interim meeting, we postpone the resolution of this issue until the draft is ready for WGLC.
I think this can be closed now. We have discussed and done the agreed optimizations.

Hi, Following some after-meeting feedback, we think it may be wise to make the optimization mentioned in already in -09 instead of, potentially, after WGLC. This is 180 degrees compared to the proposal yesterday. Some reasoning about the change of view below. Since this optimization breaks the format of message_2, there needs to be new test vectors, updated implementations and additional interop tests. This causes further delay, also waiting for implementation feedback before we can consider the protocol stable again. By addressing this now we can absorb that time in the plan we set out for specifying and testing -09. So even if we may agree that the optimization is not necessary, considering that this is a small change it seems worth to be proactive here. Here is a PR: URL If possible, please comment by August 8. We would like merge this and submit -09 soon after that. Thanks Göran From: Lake on behalf of Mališa Vučinić Date: Friday, 30 July 2021 at 09:40 To: "EMAIL" Subject: [Lake] LAKE @ IETF 111: Follow up and minutes All, Thank you for the productive meeting yesterday. We have just posted the minutes [1] and the recording will be published shortly. Many, many thanks to Marco Tiloca and Robert Wilton for taking notes during the meeting. As agreed, we will schedule a virtual interim meeting for the end of September, beginning of October. A doodle will follow shortly. In the meantime, enjoy the summer period! Mališa [1] URL