Draft: draft-ietf-lake-edhoc

Commentary: I a recommendation as well . I think this can be merged . 
 Looks fine to me , merging 
 states Then has which is using -15 ( SHA-256/64 ) , not -16 ( SHA-256 ) for the hash . How was this decision arrived at ? 
 Thanks for the comment . The hash algorithm used in x5 t is independent of the EDHOC cipher suite , that should probably be mentioned in the draft . I will make a PR with some text on this . I do n't think there was any discussion on this , but  feels like a natural choice . As EDHOC integrity protects the whole certificate the length of the hash does not have any security relevance , the hash is just used to find the certificate , not to prove it is the correct one . Using SHA-256 would increase overhead with 24 bytes per message without any benefits . An implementation supporting SHA-256 can easily support  ( as it is just a truncated SHA-256 ) . 
 Than I need to run an update on test vectors for p256 as I have switched to SHA256 . I will make an update to use SHA256/64 and pull request 
 Yes , please do . Using SHA-256 in x5 t is just a waste of 24 bytes in message2 and message3 . We should maybe give some recommendations in the draft regarding this , but I think it is hard to give normative requirements as x5 t is just one example and future COSE header parameters and EAD might use cryptographic algorithms . The algortithms in X.509 in another example on algorithms not controlled by the cipher suite ,  might use a cert with a  authentication key where the CA used RSA - PSS to sign the certificate together with cipher suite 2/3 . Maybe the draft should recommend the use of algorithms from the ciphersuite also in cose headers , EAD , X.509 , CWT , etc . In the case of x5 t the recommendation could be to use the same hash function but with as much truncation as possible . 
 Can we close this now ? 
 Works for me - thanks .
Paragraph (version A):
An EDHOC cipher suite consists of an ordered set of algorithms from
the "COSE Algorithms" and "COSE Elliptic Curves" registries as well
as the EDHOC MAC length.  All algorithm names and definitions follows
from COSE I-D.ietf-cose-rfc8152bis-algs.  Note that COSE sometimes
uses peculiar names such as ES256 for ECDSA with SHA-256, A128 for
AES-128, and Ed25519 for the curve edwards25519.  Algorithms need to
be specified with enough parameters to make them completely
determined.  The MAC length MUST be at least 8 bytes.  EDHOC is
currently only specified for use with key exchange algorithms of type
ECDH curves, but any Key Encapsulation Method (KEM), including Post-
Quantum Cryptography (PQC) KEMs, can be used in method 0, see pqc.
Use of other types of key exchange algorithms to replace static DH
authentication (method 1,2,3) would likely require a specification
updating EDHOC with new methods.
Paragraph (version B):
An EDHOC cipher suite consists of an ordered set of algorithms from
the "COSE Algorithms" and "COSE Elliptic Curves" registries as well
as the EDHOC MAC length.  All algorithm names and definitions follows
from COSE I-D.ietf-cose-rfc8152bis-algs.  Note that COSE sometimes
uses peculiar names such as ES256 for ECDSA with SHA-256, A128 for
AES-128, and Ed25519 for the curve edwards25519.  Algorithms need to
be specified with enough parameters to make them completely
determined.  The MAC length MUST be at least 8 bytes.  Any
cryptographic algorithm used in the COSE header parameters in ID_CRED
is selected independently of the cipher suite.  EDHOC is currently
only specified for use with key exchange algorithms of type ECDH
curves, but any Key Encapsulation Method (KEM), including Post-
Quantum Cryptography (PQC) KEMs, can be used in method 0, see pqc.
Use of other types of key exchange algorithms to replace static DH
authentication (method 1,2,3) would likely require a specification
updating EDHOC with new methods.
Paragraph (version A):
The output size of the EDHOC hash algorithm MUST be at least
256-bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256
truncated to 64-bits) SHALL NOT be supported for use in EDHOC except
for certificate identification with x5t and c5t.  For security
considerations of SHA-1, see RFC6194.
Paragraph (version A):
The EDHOC MAC length MUST be at least 8 bytes and the tag length of
the EDHOC AEAD algorithm MUST be at least 64-bits.  Note that
secp256k1 is only defined for use with ECDSA and not for ECDH.  Note
that some COSE algorithms are marked as not recommended in the COSE
IANA registry.
Paragraph (version B):
The output size of the EDHOC hash algorithm MUST be at least
256-bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256
truncated to 64-bits) SHALL NOT be supported for use in EDHOC except
for certificate identification with x5t and c5t.  For security
considerations of SHA-1, see RFC6194.  As EDHOC integrity protects
the whole authentication credential, the choice of hash algorithm in
x5t and c5t does not affect security and it is RECOMMENDED to use the
same hash algorithm as in the cipher suite but with as much
truncation as possible, i.e, when the EDHOC hash algorithm is SHA-256
it is RECOMMENDED to use SHA-256/64 in x5t and c5t.  The EDHOC MAC
length MUST be at least 8 bytes and the tag length of the EDHOC AEAD
algorithm MUST be at least 64-bits.  Note that secp256k1 is only
defined for use with ECDSA and not for ECDH.  Note that some COSE
algorithms are marked as not recommended in the COSE IANA registry.