Draft: draft-ietf-lake-edhoc

Commentary: 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 should n'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 : 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 : 
 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 . 
  a comment on an issue in the old repo which probably was intended to be on this issue : 
 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 i d 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 do n'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 : 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 .
Mailing list commentary: Hi , Following some after - meeting feedback , we think it may be wise to make the optimization mentioned in # 103 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 : If possible , please comment by August 8 . We would like merge this and submit soon after that . Thanks Göran
Paragraph (version A):
Compute the transcript hash TH_2 = H( H(message_1), data_2 ) where
H() is the hash function in the selected cipher suite.  The
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.
Paragraph (version B):
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
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.