Draft: draft-ietf-lake-edhoc

Commentary: Merging this as announced on the mailing list . 
 I 've started to work on the update of -traces , see . What is missing is : Trace 2 : SUITESI = [ 6 , 2 ] instead of 2 . Trace 2 : Add bytes for raw x.509 ( in addition to the CBOR encoded , see ) In total two new entries : CREDI ( Raw Value ) and CRED_R ( Raw Value ) Trace 2 : Pretty print of all byte strings the analogue of for p256 16 bytes per row space between bytes Marek 's address could you help out here ? There is also TODO on version and reference which we need to fix , but that 's just an editorial . 
 Hi Sorry i was super loaded at work last few days . I will have a look on this and also your email tomorrow or the . Best M 
 Submission deadline Monday in 10 days :-) 
 Done here : Please review and sorry for the delay 
 Thanks for the update . Started to update trace 2 , ran into this : How is this CBOR encoding made ? I would have expected to be encoded as and as 
 Hi There was an incompatibility in the generator function for identifiers . This has been fixed here : and updated test vectors are here : 
 Thanks , I 'll take a look later today . 
 New test vector included in trace 2 . 
 We are still missing update of label / remove of " Master " in trace 1 , per . Could anyone of you help ? ( Replace " OSCOREMasterSecret / Salt " with " OSCORE_Secret / Salt " and re - generate test vector for EdDSA in ) 
 For the first trace using EdDSA , with the new labels " OSCORESecret " and "  " , I derive : OSCORE Master Secret ( Raw Value ) ( 16 bytes ) OSCORE Master Salt ( Raw Value ) ( 8 bytes ) OSCORE Master Secret after KeyUpdate ( Raw Value ) ( 16 bytes ) OSCORE Master Salt after KeyUpdate ( Raw Value ) ( 8 bytes ) Can anyone confirm ? 
 These updates are now completed in -traces . 
 PR , which is merged with master , changed Exporter labels for OSCORE : The test vectors need to be updated accordingly , to be able to submit a new version of -traces matching the next version of -edhoc . (  : 
 PR done . 
 Thanks , merged . 
 RFC 8446 states : " Note : With common hash functions , any label longer than 12 characters requires an additional iteration of the hash function to compute . The labels in this specification have all been chosen to fit within this limit . " 12 is specific for TLS , but even if the number is slighty higher for EDHOC the following labels might currently require an extra iteration . Label : OSCOREMasterSecret Label : OSCOREMasterSalt I would suggest we calculate the exact length for EDHOC . Add that length as a consideration in the draft . And shorted down any long labels to not be longer . 
 I think removal of master is it 's own issue . While we can update the terminology in an update , the labels are frozen and can not be changed . 
 Appreciated , as these are strings lugged around in every firmware update . 
 Closing since is merged . 
 Updating my implementation , I noticed that these are in a CBOR structure anyway ( and not concatenated into strings ) . So as these are all registered , why not go all the way and make them integers ? 
 label : tstr What do you want to make integers ? 
 The labels -- given they are coming from a registry anyway . ( Why go " OSCOREmastersecret " to " OSCORE_secret " when we could go to 23 as well . ( I realize it 's little savings , like 60 bytes of firmware size ; might not be worth much , but if there 's a time for it , it 's now ) 
 That makes sense to me 
 Right , we could use something else instead of unique text strings . The current construct is : EDHOC - Exporter(label , context , length ) = EDHOC - KDF(PRK4x3 m , TH4 , label , context , length ) If not label , then context ( bstr ) can be unique for this use of PRK4x3 m and TH4 . Is the proposal to register unique byte strings , or to change the definition of the function ? 
 Reopening this issue , since there is new input . 
 Still not clear to me what to register instead of labels and how to use in Exporter . There are multiple options . ( I assume this only applies to Exporter , not " KEYSTREAM_2 " etc . ) But perhaps first ask more people . others : Is replacing exporter labels with e.g. integers a good change ? 
 The proposal is to replace all inputs that ever go into the " label " argument -- anything else would be adding complexity . For a concrete proposal , we would change to and define , in order of occurrence in the document : with all occurrences of with etc . The exporter registry would then grow a n int field , and look like this : ( It does n't matter here that there is overlap in the values -- just as it was never ruled out that " K3 " could become a label in the string based EDHOC Exporter Label Registry . That has and still is OK because it 's used with different PRKs and transcript hashes . At any rate it 's good that all these stay under 23 even with some room for other users , so implementers can store things preencoded if they so desire . ) As for the security analyses , the numbers have the same properties as the strings -- they are self - delimited , and relative uniqueness properties should be the same no matter whether it 's strings or numbers ( at least when dealing in absolutes ; if someone picked an unregistered number at random they 're more likely to pick an assigned one than with strings , but that was already " maybe broken " ) . Length of input is reduced , but that is part of the point , and removing the " _ Master " was fine already . 
 Based also on further discussions with If the change is made to have   , this should happen to all the labels involved . That is , not only to the labels provided as input to EDHOC - Exporter ( ) , but also to the labels "  " etc . that are a direct input to EDHOC - KDF ( ) . This avoids having an implementation of EDHOC - KDF ( ) to handle both types as possible input . The labels to actually register should still be only those intended as input to EDHOC - Exporter ( ) , i.e. , there is no need to register integer labels that are a direct input to EDHOC - KDF ( ) ( corresponding to the current "  " etc . ) . In fact , same integer values would not be a problem in practice , since PRK4x3 m clearly points to the exporter labels when used as first argument in EDHOC - KDF ( ) . What can be useful is to make clear , as much as now for the tstr version , that potential labels defined in the future as part of EDHOC extensions and to directly use with EDHOC - KDF ( ) have to be different from those already defined in that space , i.e. , "  " etc . 
 Changing label to integers seems fine with me . I do n't see why the Label below would stay in the specification . This would just be a variable name in the implementation , or?I assume that there is no benefit with int here as the uint is not sent on the wire . 0 - 255 would be stored as a single byte in the program and then converted to cbor when used . 
 Note that somebody suggested that this is good to to as late as possible just to break compability . 
 Based on the input from the formal verification , we will likely have 3 more internal EDHOC labels .  something like the following : Derived from PRK2e   Derived from PRK3e2 m    LABELSALT3e2 m Derived from PRK3 m LABELMAC3 LABELPRK_OUT 
  in PR . Close this when that is merged .
Paragraph (version B):
With SHA-256, no context, and OKM length smaller than 24, any label
longer than 20 characters requires an additional iteration of the
hash function to compute.  The labels in this specification have all
been chosen to fit within this limit.