Draft: draft-ietf-lake-edhoc

Commentary: ( Last two commits on wrong branch . ) 
 The prototype of EDHOC - Exporter ( ) has remained EDHOC - Exporter(label , length ) , while it should be EDHOC - Exporter(label , context , length ) as per Alternative 3 discussed in issue Correct ? 
 Thanks your comment is addressed in the latest commit . I merge this now . 
 The text use both the terms " session " and " protocol instance " , would be good to settle for one term . 
 Just chose one , I do n't think this needs an issue 
 In the security considerations " session " makes most sense to me . There is also the term " connection " . I will make a proposal . 
 The spec should likely forbid multiple calls to the EDHOC - Exporter interface with the same label , in order to prevent the same key being reused . Discussed with and 
 Good catch . Yes , we should have some text about that , but it should probably more be a requirement on the application using EDHOC that on EDHOC itself . Two different application should defintly not use the same label . The same application might rederive the same key several times as long as it keep track of its AEAD nonces and replay window . I thought that we had already IANA registry proposed for this , but that is not the case . We should probably have one . If we have a IANA registry the labels get more fixed and it might be that we need a context input parameter as well . 
 If we make a IANA registrer for labels , I think we need to let the application add additional information in some way . Two alternatives : make an IANA register for label prefixes , and let the application append information to the label prefix . This was recently planned for EAP - TLS ( and methods built on EAP - TLS ) but was changes because the TLS export labels are not really ment to be labels . This would not change the current exporter interface . expand the interface with a context parameter . This is similar to the TLS exporter . A problem with the TLS exporter is that some implementations decided to not even support context . 
 how is the context parameter intended to be used ? Could you give an example ? Would this be some sort of " salt " when deriving the key ? 
 Do n't register labels , register label prefixes . 
 The motivation for " context " or " label postfixes " is to increase the flexibility for the application . Restricting the application to IANA registered labels is very limiting . An application might want to use the EDHOC exporter to derive a number of keys and we should encourage that . The alternative is that the application needs to implement its own key derivation , which might be less secure and might be outside of the TEE . I called it " context " just because TLS calls the paramater in its exporter context . 
 " Be like TLS " is of course a good motivation . Technically , a label prefix is not different from a context , it just saves the need to separate prefix and suffix . 
 ( And of course there is nothing wrong with multiple calls with the same label ; the application has a " right to forget " :-) 
 The solutions should be equal when it comes to security . The choice should be made based on what is easiest for implementators and apllications using EDHOC . Alt 1 . We make an IANA register for label prefixes : " OSCORE Master Secret " " OSCORE Master Salt " The Export function stays the same : EDHOC - Exporter(label , length ) = EDHOC - KDF(PRK4x3 m , TH4 , label , length ) An application is allowed to append things to the label prefix : " OSCORE Master Secret " " OSCORE Master Secret PickleRick " Alt 2 . We make an IANA register for labels : label = " OSCORE Master Secret " label = " OSCORE Master Salt " The Export function needs to change : EDHOC - Exporter(label , ctx , length ) = EDHOC - KDF(PRK4x3 m , TH4 , [ label , ctx ] , length ) An application is not allowed to append things to the label and uses the ctx instead : label = " OSCORE Master Secret " ctx = " " label = " OSCORE Master Secret " ctx = " PickleRick " 
 No major opinion . Alt 2 breaks the test vector for the OSCORE security context . It would be good to get more input . 
 Any preference ? 
 If desired the CTX is more convenient it can always be in a wrapper on top of EDHOC - Exporter ( ) . ( I assume re - use of label+ctx in Alt 2 is equivalent to re - use of label in Alt 1 ? ) 
 I prefer to have explicitly specified . We can pass to the concatenation of and . When is undefined / empty , test vectors are not affected . I guess this is what is referring to ? 
 label is a CBOR byte string . While alt 2 use an CBOR array . Definging alt2 as a wrapper seems more complication in my view . 
 Would be good if people stated alt 1 . or alt 2 . or made a concrete suggestion for alt 3 . 
 Alt 3 ( CBOR sequence ) We make an IANA register for labels : label = " OSCORE Master Secret " label = " OSCORE Master Salt " The Export function needs to change : EDHOC - Exporter(label , ctx , length ) = EDHOC - KDF(PRK4x3 m , TH4 , labelcontext , length ) where is a CBOR sequence : If you want to keep the test vectors intact , then you could make optional in the CDDL , but not sure how to specify an optional parameter in the interface definition . 
 Thanks . That is a valid alt 3 . but ctx should probably be a bstr 
 I do n't think keeping the test vectors intact is an important goal at all . Let 's decide on what is simplest for a user of the exporter interface . 
 Something like that , yes . Later post do differentiate the type of " label " and " ctx " and in light of that and changing test vectors Alt3 seems clean . 
 I am fine with alt 3 . I can start making PR for that unless somebody has different ideas . I do n't alt 1 is a good alternative anymore as is restricts context to being a unicode string . Which would require some base64 encoding or similar for a general context . 
 Please review alt . 3 as specified in . Unless there are any comments we would like to merge this . 
 This is included in -07 so I close the issue . 
 Comment by   in " The draft does a good job of pointing to the right places in RFC 8152 , but I still ended up trying to understand another ~100 page document just to implement the few constructs I actually needed . " Should we provide more details about COSE constructs , e.g. in appendix A.2 ? 
 ( pasting my response from the mailing list here for completeness ) Thanks for following up on this . Yes , in my opinion expanding on the COSE constructs would be helpful . But I also sympathize with not wanting to duplicate what is already defined in another RFC ( and possibly getting it wrong , as Carsten points out ) . Considering that there are quite a few implementers already and besides mine you have only received one other similar comment , maybe this is n't an issue for a meaningful majority . In any case , the draft has made great strides already in terms of accessibility and is in a good state now , so I do n't see improvements in this area as an absolute necessity . 
 The two COSE constructs that are used in EHDOC , and are fairly simple . They do n't use the recursive structure or embed . I think it is possible to add some additional clarifications on the structure of the COSE messages in the EHDOC draft without having to copy too much text from RFC 8152 .
Mailing list commentary: As part of a thesis I built a proof - of - concept implementation of EDHOC in the Rust programming language available at . The naming of the repository is due to the subject being both EDHOC and OSCORE on embedded devices , but the following refers only to the EDHOC implementation . It 's based on draft - selander - ace - cose - ecdhe-14 and as such , sadly , outdated . Since it was just one part of the overall work , I only managed to implement the subset I needed , which is RPK and the signature - signature based scheme ( corresponding to what draft - selander - lake - edhoc calls method 0 ) . I also took some other shortcuts , such as not supporting auxiliary data . Fortunately , test vectors were about to be introduced just around the time I was working on it , so I ' ve been able to successfully verify my implementation against them when shared them with me for some preliminary testing . Since I did n't have any prior experience implementing this kind of software , I would definitely consider it more of an experiment , but it 's out there and it works , in case it can be useful to anybody . I ' m convinced that EDHOC will be valuable particularly in the context of OSCORE , possibly even beyond that . As for the draft itself , I would like to mention one aspect that I think could be improved from the perspective of an implementer . Part of the promise of EDHOC is that it 's simple and lightweight due to reusing COSE . That is certainly the case , but breaks down somewhat when working on a system where no fully featured library for it is available . This was the case for me and I personally found it difficult to quickly figure out which aspects of COSE I needed to implement . The draft does a good job of pointing to the right places in RFC 8152 , but I still ended up trying to understand another ~100 page document just to implement the few constructs I actually needed . I know the authors are aware of this and there has been some effort to inline more information directly in the specification , which I greatly appreciate . It would be very nice to have an entirely self - contained document to work with . But I have to again point out my lack of experience in that area , it 's entirely possible that this draft is in fact much better than others in this regard and I just do n't know it yet . With that I would like to support the adoption and am looking forward to seeing how it develops . Kind regards ,
Paragraph (version A):
where label is a tstr defined by the application and length is a uint
defined by the application.  The label SHALL be different for each
different exporter value.  The transcript hash TH_4 is a CBOR encoded
bstr and the input to the hash function is a CBOR Sequence.
Paragraph (version A):
where H() is the hash function in the selected cipher suite.  Example
use of the EDHOC-Exporter is given in I-D.ietf-core-oscore-edhoc.
Paragraph (version B):
where label is a registered tstr from the EDHOC Exporter Label
registry (exporter-label), context is a bstr defined by the
application, and length is a uint defined by the application.  The
(label, context) pair must be unique, i.e. a (label, context) MUST
NOT be used for two different purposes.  However an application can
re-derive the same key several times as long as it is done in a
secure way.  For example, in most encryption algorithms the same
(key, nonce) pair must not be reused.
Paragraph (version B):
The transcript hash TH_4 is a CBOR encoded bstr and the input to the
hash function is a CBOR Sequence.
Paragraph (version B):
where H() is the hash function in the selected cipher suite.
Examples of use of the EDHOC-Exporter are given in asym-msg4-proc and
I-D.ietf-core-oscore-edhoc.