Draft: draft-ietf-lake-edhoc

Commentary: In the latest commit there are new names to distinguish infolabel and exporterlabel , the former is extended to be int . I also noted an error in the CDDL reference section C.2 . 
 The current design of encryption of message2 in EDHOC limits the size of the message to 8160 bytes when  is used . Is that a problem ? message2 consists of the fields GY IDCREDR SignatureorMAC2 CR and optional fields : ? PAD2 ? EAD2 While these message fields could be very small , depending on use case , some may be arbitrarily large . The field IDCREDR would typically be a reference to an authentication credential , but may contain the credential itself , for example a certificate chain . EAD2 is defined by the application so may a priori be large . One example is revocation information .  : SHA-384 has the limit bytes and SHA-512 has the limit bytes . SHAKE128 and SHAKE256 have much much larger limits ( 2 ^ 2040 − 1 bits ) 
 Some of the alternatives : Do nothing / this is not a problem Replace  with HKDF ' , which allows larger length of output   for message2 size < 8160 , HKDF ' for larger message2 Replace message_2 encryption with AES - CTR / ChaCha20 Use KMAC instead of HKDF Edit : Multiple applications of HKDF , to produce sufficiently long keystream  : HKDF ' here refer only to HKDF - Expand . HKDF - Extract would stay the same .  : HKDF ' would still be HKDF but not HKDF as specified in RFC 5869 . The original HKDF paper just states that the counter is fixed length . RFC 5869 unfortunately chose 1 byte . 
 It seems that this is a concern if / when GY or SignatureorMAC2 becomes one of the monstrous Post - Quantum algorithms , or a HSS . I think that we should rule that out of scope , say that when it happens that we 'll do EDHOC2 based upon new constraints at the time . I think that 8 K is probably enough for the certificate chain . That 's a lot ( 100 ) of 802.15.4 fragments . So unless switching to HKDF ' is really cheap , do n't bother . 
 Thanks  . Yes , the assumption so far has been " this is not a problem " . It would be good to understand the impact on implementation if we would come to a different conclusion . Please comment , on the examples below . Replace  with HKDF ' , which allows larger length of output HKDF is constructed from HMAC using a counter which is 8 bits long . By defining HKDF ' with 16 / 32 bits counter would make the output 2 MB / 137 GB ( if I did the maths right ) before the counter wraps . How is HKDF implemented today ? Is it feasible to define your own variant , say with 32 bits counter ? Use HKDF for message2 size < 8160 , HKDF ' for larger message2 If this solution is applied , and only HKDF was mandatory to implement , then applications which stay below the limit would have minor impact . Yet it still allows support for all practical message2 sizes at the cost of implementing HKDF ' and the use of two KDFs . Is this an interesting option ? Replace message2 encryption with AES - CTR / ChaCha20 These are of course well known algorithm . Is AES - CTR available in libraries used , or would you need to implement it from AES ? This introduces a dependence of ciphersuite , or the need to add another entry to the cipher suite for message2 encryption algorithm . Use KMAC instead of HKDF For KMAC , output length < 2 ^ 2040 . But then we lost the case when there is no KMAC available . as many keystreams as needed to cover PLAINTEXT2 Divide PLAINTEXT2 in fixed size chunks ( of 8160 bytes or similar ) + last chunk . Introduce dependency on chunk number n = 0 , 1 , 2 , 3 , ... in one of the first three arguments of the keystream derivation : For example : PRK2e(n ) = Extract ( salt , IKM ) = HMAC - SHA-256 ( n , GXY ) or replace 0 with negative labels : -n for chunk n or replace TH2 with context = < < n , TH_2 
 PR is included in -16
Paragraph (version A):
The (label, context) pair used in EDHOC-Exporter 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 can be reused with different nonces.  The
context can for example be the empty CBOR byte string.
Paragraph (version B):
The (exporter_label, context) pair used in EDHOC-Exporter must be
unique, i.e., an (exporter_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 can be reused
with different nonces.  The context can for example be the empty CBOR
byte string.