Draft: draft-ietf-lake-edhoc

Commentary: This PR addresses and as well as parts of and . I also thought is was good to point out that AES - CCM-16 - 64 - 128 and AES - CCM-16 - 64 - 128 are compatible with the IEEE CCM * mode . I also corrected the sentence " wrapped in a bstr " that  pointed out during the interim . 
 Looks ready to merge 
 Duplicated text in 3.5.2 . and 3.6 : " The authentication key algorithm needs to be compatible with the EDHOC key exchange algorithm when static Diffie - Hellman authentication is used , and compatible with the EDHOC signature algorithm when signature authentication is used . " 
 Is it relevant to have post - quantum cipher suites see 
 EDHOC already supports PQC signatures in the form of LMS . Any PQC signatures to COSE will also be supported by EDHOC . For Key Exchange it is a bit more complex . Supporting KEMs will likely require some changes . The conslusion in the requirement document was that : " PAKE , post - quantum and " hybrid " ( simultaneously more than one ) key exchange is out of scope , but may be supported in a later version . " 
 We also looked into if EDHOC with ECC should be moved to KEMs to be able to ( more or less ) automatically support PQC Kems , but the resulting protocol would have been more heavy as some properties of ECC could not be used in a strict KEM design . I think both PAKEs and KEMs would require new methods . Each PAKE might require its own method while all KEMs could likely be supported together . Unclear if 3x PQX KEM is better than 1 PQC KEM and 2 PQC Signatures , that requires some analysis . 
 Maybe we looked a bit to much on the Static DH mode when KEM was discussed last . Mehtod 0 will automatically work with PQC KEMs . GX is the public key and GY is an key encapsulation / ciphertext . We should likely describe that in the text . Good that you brought this up again This would not be a technical change at all for method 0 . The other methods would not work for general KEMs . 
 Although I 'm not convinced all aspects of " PQ " can be solved in EDHOC timeframe , I still think it makes sense to put this in the document already . 
 My current plan would be to point out that the Key Exchange in method 0 is already following the KEM interface and can be replaced by any KEM including PQC KEMs . Might also be good to point out that method works with any signature algorithm including the PQC signature algorithm LMS that COSE has already specified . 
 that for raising the issue earlier in and please review the new PR Method 0 is well - prepared for PQC algorithms , you can just replace the current KEM and Signature algorithms with PQC algorithms . Many of the PQC algorithms are very fast . Note that using PQC algorithms significantly increases the message sizes . Signatures , public keys , and encapsulations would be around 800 bytes instead of the current 32 - 64 bytes . 
 Does it make sense to specify a suite ? 
 Regarding increased size , it does not meet the charter objective / fragmentation limit of 6TiSCH , but it still fits the MTU 6lowpan and may be a price to pay to reach PQC . Can the OSCORE re - keying proposals also meet PQC requirements ? If so , and a " relatively expensive " key - exchange can be done very infrequently - the overhead is less of an issue . 
 Not right now I think . I think EDHOC needs to wait until COSE has registered PQC Key exchange algorithms . Which will probable happen after NIST standards . I do n't think combining LMS signatures with ECC key exchange makes sense . NIST stated that round 3 will end close to the end of 2021 . Draft standards will be available 2022 - 2023 and final standards hopefully 2024 . NSA has stated that will update their CNSA suite at the end of NIST round 3 . I think that makes a lot of sense for US TOP SECRET that requires protection for maybe 50 - 100 years . For many other use cases I think the quantum threat might bw a bit exagerated . It is unclear if CRQC will ever be built . If the number of qubits double every 18 months like transistor based chips did it will take 25 - 30 years . 
 Regarding increased size , it does not meet the charter objective / fragmentation limit of 6TiSCH , but it still fits the MTU 6lowpan and may be a price to pay to reach PQC . COSE / EDHOC will definitly have PQC algorithms in a few years . A big US company asked for a CNSA compliant suite which was . CNSA will be updated to PQC is just a few months , but I think EDHOC should wait for COSE when it comes to PQC . Can the OSCORE re - keying proposals also meet PQC requirements ? If so , and a " relatively expensive " key - exchange can be done very infrequently - the overhead is less of an issue . Basically any symmetric construction will be PQC . The current It is unclear if CRQC breaking RSA will ever be built . If such CRQC are ever built , it would take millions of such CRQC hundreds of years to break AES-128 .  is more quantum resistant then AES-128 and HMAC - SHA-256 is more resistant than SHA-256 . NIST currently draft documents label AES-128 and  as quantum resistant which make a lot of sense to me . The EDHOC Key - Update use HMAC - SHA-256 and the OSOCRE key update use HKDF - SHA-256 . They would both be highly resistant to quantum computers . 
 is now merged into master . Any further comments ? 
 It looks good to me , and i appreciate the progress moving forward . 
 All good from my side too . Thanks ! 
 Several things in the document is not specification but rather clarification of how COSE works . The additon of this and the integration in the main body was requested by several implementors . It should be more clearly marked that these parts just explain COSE and does not define anything . If soemthing would be wrong . The COSE specification apply . E.g. 
 The explanations of COSE are moved to C.3 in PR . 
 The IANA section currectly specified that CWT can be sent tagged or untagged while UCCS can only be sent untagged . That is probably not how it should be . 
 Only untagged : Untagged or tagged : Only tagged 
 Tagged add bytes that are not required . The COSE header parameter alredady gives this information . Except that I do n't have a strong opinion between allowing both and only allowing untagged . Note that this is mostly a COSE question , rather than LAKE 
 The UCCS tag numer has not been assigned yet . 
 If I understand correctly , there is no need to integrity - protect also the possible CBOR tags . Then , I 'd propose to generally admit both tagged and untagged objects . However , possible CBOR tags must be stripped away when building CRED_X --- Relates to 
 If I understand correctly , there is no need to integrity - protect also the possible CBOR tags . There is no need , but if used in the protected header as in EDHOC they will be integrity protected . That however not a problem as the protected header_map is sent on the wire , so both parties will have the same formatting . 
 Thanks  . My understandanding of the the current suggestion from  is : COSE : The COSE header parameters for CWT and ECCS allow bot tagged and untagged and do not enforce any specific order in the map . EDHOC : When CWT and UCCS is used in EDHOC , then CRED_x is the untagged CWT or UCCS sorted in lexigraphical order as defined by deterministic CBOR . That works for me . 
 Do CWT and UCCS need several header parameter each similar to x5u x5 t x5chain  ? 
 New name ( kcwt / kccs ) and description : 
 commented in the interim on " wrapped in a bstr " needs to be clarified . 
 Is this following minor change ( in ) sufficient , or do we need to provide more details ? OLD When the authentication credential is a X.509 certificate , CREDx SHALL be the end - entity DER encoded certificate wrapped in a bstr { { I - D.ietf - cose - x509 } } . NEW When the authentication credential is an X.509 certificate , CREDx SHALL be the end - entity DER encoded certificate , encoded as a bstr { { I - D.ietf - cose - x509 } } . 
 Do you have a nested encoding step or is this just a byte string with the encoded X.509 certificate ? 
 As this is referring to the end - entity certificate I would say the latter . 
 Or in other words , we need to make sure we do n't use terminology that implies nested encoding steps in cases where we simply have a plain data item in the CBOR . In CBOR diagnostic , if ' foo ' is the encoded foreign data : ' foo ' Inside the overall encoded data item : < < ' foo ' Inside the overall encoded data item : 
 As I read it " end - entity DER encoded certificate , encoded as a bstr " indicates a " plain " CBOR encoding of the non - CBOR X.509 certificate data . Any objection / disagreement to this definition / interpretation ?
Paragraph (version A):
To prevent misbinding attacks in systems where an attacker can
register public keys without proving knowledge of the private key,
SIGMA SIGMA enforces a MAC to be calculated over the "identity".
EDHOC follows SIGMA by calculating a MAC over the whole credential,
which in case of a X.509 or C509 certificate includes the "subject"
and "subjectAltName" fields, and in the case of CWT or CCS includes
the "sub" claim.  While the SIGMA paper only focuses on the identity,
the same principle is true for other information such as policies
associated to the public key.
Paragraph (version B):
To prevent misbinding attacks in systems where an attacker can
register public keys without proving knowledge of the private key,
SIGMA SIGMA enforces a MAC to be calculated over the "identity".
EDHOC follows SIGMA by calculating a MAC over the whole credential,
which in case of an X.509 or C509 certificate includes the "subject"
and "subjectAltName" fields, and in the case of CWT or CCS includes
the "sub" claim.  While the SIGMA paper only focuses on the identity,
the same principle is true for other information such as policies
associated to the public key.
Paragraph (version A):
The authentication key (i.e. the public key used for authentication)
MUST be a signature key or static Diffie-Hellman key.  The Initiator
and the Responder MAY use different types of authentication keys,
e.g., one uses a signature key and the other uses a static Diffie-
Hellman key.  The authentication key algorithm needs to be compatible
with the method and the cipher suite.  The authentication key
algorithm needs to be compatible with the EDHOC key exchange
algorithm when static Diffie-Hellman authentication is used and
compatible with the EDHOC signature algorithm when signature
authentication is used.
Paragraph (version B):
The authentication key (i.e. the public key used for authentication)
MUST be a signature key or static Diffie-Hellman key.  The Initiator
and the Responder MAY use different types of authentication keys,
e.g., one uses a signature key and the other uses a static Diffie-
Hellman key.  The authentication key algorithm needs to be compatible
with the method and the cipher suite.  The authentication key
algorithm needs to be compatible with the EDHOC key exchange
algorithm when static Diffie-Hellman authentication is used, and
compatible with the EDHOC signature algorithm when signature
authentication is used.
Paragraph (version A):
When the authentication credential is a X.509 certificate, CRED_x
SHALL be the end-entity DER encoded certificate wrapped in a bstr
I-D.ietf-cose-x509.
Paragraph (version B):
When the authentication credential is an X.509 certificate, CRED_x
SHALL be the end-entity DER encoded certificate, encoded as a bstr
I-D.ietf-cose-x509.
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.  Algorithms need to be specified with enough
parameters to make them completely determined.  EDHOC is only
specified for use with key exchange algorithms of type ECDH curves.
Use with other types of key exchange algorithms would likely require
a specification updating EDHOC.  Note that for most signature
algorithms, the signature is determined by the signature algorithm
and the authentication key algorithm together, see auth-keys.  The
authentication key algorithm needs to be compatible with the EDHOC
key exchange algorithm when static Diffie-Hellman authentication is
used and compatible with the EDHOC signature algorithm when signature
authentication is used.
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.  Algorithms need to be specified with enough
parameters to make them completely determined.  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):
EDHOC supports all signature algorithms defined by COSE, including
PQC signature algorithms such as HSS-LMS.  Just like in TLS 1.3
RFC8446 and IKEv2 RFC7296, a signature in COSE is determined by the
signature algorithm and the authentication key algorithm together,
see auth-keys.  The exact details of the authentication key algorithm
depend on the type of authentication credential.  COSE supports
different formats for storing the public authentication keys
including COSE_Key and X.509, which have different names and ways to
represent the authentication key and the authentication key
algorithm.
Paragraph (version B):
As of the publication of this specification, it is unclear when or
even if a quantum computer of sufficient size and power to exploit
public key cryptography will exist.  Deployments that need to
consider risks decades into the future should transition to Post-
Quantum Cryptography (PQC) in the not-too-distant future.  Many other
systems should take a slower wait-and-see approach where PQC is
phased in when the quantum threat is more imminent.  Current PQC
algorithms have limitations compared to Elliptic Curve Cryptography
(ECC) and the data sizes would be problematic in many constrained IoT
systems.
Paragraph (version B):
Symmetric algorithms used in EDHOC such as SHA-256 and AES-CCM-
16-64-128 are practically secure against even large quantum
computers.  EDHOC supports all signature algorithms defined by COSE,
including PQC signature algorithms such as HSS-LMS.  EDHOC is
currently only specified for use with key exchange algorithms of type
ECDH curves, but any Key Encapsulation Method (KEM), including PQC
KEMs, can be used in method 0.  While the key exchange in method 0 is
specified with terms of the Diffie-Hellman protocol, the key exchange
adheres to a KEM interface: G_X is then the public key of the
Initiator, G_Y is the encapsulation, and G_XY is the shared secret.
Use of PQC KEMs to replace static DH authentication would likely
require a specification updating EDHOC with new methods.