Original text:
"EDHOC_IV_4", respectively.  IVs are only used if the EDHOC AEAD algorithm uses IVs.  4.4. To provide forward secrecy in an even more efficient way than re-

Reviewer comments:
Merging this as announced on the mailing list.
I've started to work on the update of -traces, see c936328e. 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 c936328e) In total two new entries: CREDI (Raw Value) and CRED_R (Raw Value) Trace 2: Pretty print of all byte strings the analogue of URL for p256 16 bytes per row space between bytes Marek's address NAME 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
NAME Submission deadline Monday in 10 days :-)
Done here: URL Please review and sorry for the delay
NAME 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: URL and updated test vectors are here: URL
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 . NAME NAME Could anyone of you help? (Replace "OSCOREMasterSecret/Salt" with "OSCORE_Secret/Salt" and re-generate test vector for EdDSA in URL)
For the first trace using EdDSA, with the new labels "OSCORESecret" and "OSCORESalt", I derive: OSCORE Master Secret (Raw Value) (16 bytes) 9565355973280280d64a3ce8d7fa0a93 OSCORE Master Salt (Raw Value) (8 bytes) 37478eddb09e5d7a OSCORE Master Secret after KeyUpdate (Raw Value) (16 bytes) ad4870dc7aca505bf80868785bd40d1b OSCORE Master Salt after KeyUpdate (Raw Value) (8 bytes) 7138715cb50303a2 Can anyone confirm?
These updates are now completed in -traces.
PR , which is merged with master, changed Exporter labels for OSCORE: URL The test vectors need to be updated accordingly, to be able to submit a new version of -traces matching the next version of -edhoc. (Att: NAME NAME
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 cannot 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(PRK4x3m, TH4, label, context, length) If not label, then context (bstr) can be unique for this use of PRK4x3m 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. NAME NAME 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 doesn'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 NAME If the change is made to have integer labels, 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 "KEYSTREAM2" 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 "KEYSTREAM2" etc.). In fact, same integer values would not be a problem in practice, since PRK4x3m 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., "KEYSTREAM2" etc.
Changing label to integers seems fine with me.I don'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. Likley something like the following: Derived from PRK2e LABELKEYSTREAM2 LABELSALT2e Derived from PRK3e2m LABELMAC2 LABELK3 LABELIV3 LABELSALT3e2m Derived from PRK3m LABELMAC3 LABELPRK_OUT
Resolve in PR . Close this when that is merged.

Revised text:
"EDHOC_IV_4", respectively.  IVs are only used if the EDHOC AEAD algorithm uses IVs. <ins> 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. </ins> 4.4. To provide forward secrecy in an even more efficient way than re-