jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-lake-edhoc

Commentary: IAB has started a program to look into updates of the Internet Threat Model . Looks like the outcome might be a guidance document . One new threat is centralised data collection where the other endpoint might not be acting in the interest of the users . There is not reason to change the protocol , but I think it would be good with some privacy considerations . Using the same credentail with several other endpoints enables tracking . I will make a PR soon with a reference to draft - arkko - arch - internet - threat - model - guidance 
 This has been merged for a while without any comments . Was discussed at the interim . Closing . 
 Looks good , I made some editorials .
Paragraph (version B):
Since the publication of RFC3552 there has been an increased
awareness of the need to protect against endpoints that are
compromised, malicious, or whose interests simply do not align with
the interests of users I-D.arkko-arch-internet-threat-model-guidance.
RFC7624 describes an updated threat model for Internet
confidentiality, see sec-prop.  I-D.arkko-arch-internet-threat-model-
guidance further expands the threat model.  Implementations and users
SHOULD consider these threat models.  In particular, even data sent
protected to the other endpoint such as ID_CRED and EAD can be used
for tracking, see Section 2.7 of I-D.arkko-arch-internet-threat-
model-guidance.
Draft: draft-ietf-lake-edhoc

Commentary: Suggestion base the discussion during the October interim . There was no strong opinions . This PR updates the MTI for header parameters and credential types to align with the choices made for method ( none is MTI ) . EAD is explicitly optional to support . It is used in specific cases and requires additional mechanics for each use case . 
 The things that are Mandatory or optional to support or now spread out in various places . 
 This does not need to be a new section ( like the MTI section in TLS 1.3 ) but it definitly needs to be clear what in the draft is mandatory to implement or not . Could be as simple as stating . Everything is mandatory Nothing is mandatory Something in between Currently is is undefined which is not good I think 
 I started making an MTI section inspired by RFC 8446 . I think this makes things clearer . I some editorial notes in the section that needs to be discussed . 
 MTI section now in place and no editor 's notes left .
Paragraph (version A):
Implementaions MAY support message_4.  Error codes 1 and 2 MUST be
supported.
Paragraph (version A):
Implementations MUST support 'kid' parameters of type int.
Paragraph (version A):
Editor's note: Is any COSE header parameters (kid, kcwt, kccs, x5t,
c5c, etc. ) MTI?
Paragraph (version A):
Editor's note: Is any credential type (CCS, CWT, X.509, C509) MTI?
Paragraph (version A):
Editor's note: Is support of EAD MTI?
Paragraph (version B):
Implementations MUST support 'kid' parameters of type int.  None of
the other COSE header parameters are mandatory-to-implement.
Paragraph (version B):
An implementation may support only a single credential type (CCS,
CWT, X.509, C509).  None of the credential types are mandatory-to-
implement.
Paragraph (version B):
Implementations MAY support message_4.  Error codes 1 and 2 MUST be
supported.
Paragraph (version B):
Implementations MAY support EAD.
Draft: draft-ietf-lake-edhoc

Commentary: This simplify things . The selected cipher suite also covers more than just the aead algorithm . I think the " suite = int " definition can be removed . It does not add much in the current version . In older versions suite was a more advances construction . 
 The selected cipher suite covers the aead and more . 
 selectedsuite is always included in transcripthash and could be removed . I.e. an equally secure info would be info = ( transcript_hash : bstr , label : tstr , context : bstr , length : uint , ) 
  , we can close this . 
 This has been merged to master .
Paragraph (version A):
edhoc_aead_id is an int or tstr containing the algorithm
identifier of the EDHOC AEAD algorithm in the selected cipher
suite encoded as defined in I-D.ietf-cose-rfc8152bis-algs.  Note
that a single fixed edhoc_aead_id is used in all invocations of
EDHOC-KDF, including the derivation of KEYSTREAM_2 and invocations
of the EDHOC-Exporter (see exporter).
Paragraph (version B):
selected_suite is an int containing the selected cipher suite.
Draft: draft-ietf-lake-edhoc

Commentary: CRED_R - bstr containing the credential This is not true for C509 which is an CBOR array
Paragraph (version A):
When the credential is a certificate, CRED_x is an end-entity
certificate (i.e., not the certificate chain), encoded as a CBOR
bstr.  In X.509 and C509 certificates, signature keys typically have
key usage "digitalSignature" and Diffie-Hellman public keys typically
have key usage "keyAgreement".
Paragraph (version B):
When the credential is a certificate, CRED_x is an end-entity
certificate (i.e., not the certificate chain).  In X.509 and C509
certificates, signature keys typically have key usage
"digitalSignature" and Diffie-Hellman public keys typically have key
usage "keyAgreement".
Paragraph (version A):
CRED_I - bstr containing the credential of the Initiator,
see id_cred.
Paragraph (version B):
CRED_I - CBOR item containing the credential of the
Initiator, see id_cred.
Draft: draft-ietf-lake-edhoc

Commentary: Looks good . One inconsistency is that there is no cipher suite with AES - GCM and NIST curves , like ( A128GCM , SHA-256 , P-256 , ES256 , A128GCM , SHA-256 ) . This could be a new cipher suite 5 . Then all non - CNSA suites would come in pairs . 
 That is very intentional . The GCM cipher suite uses X25519 for key exchange and ECDSA for authentication . This seems to be the dominant choice for HTTPS on the Web . Unless you are constrained you typically use X25519 for key exchange for speed and ECDSA for authentication as that is what the CAs support . For an IoT device you probably want to have a single curve implemented . Also it might be much easier to switch to EdDSA as you might not have to rely on Global CAs and all other HTTPS nodes to support EdDSA . You can just deploy you own CWT server and make sure the nodes in you new IoT deployment support EdDSA . I have not heard any IoT people very interested in GCM . People seems far more interested in ChaCha20 . 
 Ready to merge ? 
 Is it worth having 4 diiference CCM based ciphser suites . And are they the correct 4?EDHOC should probably have a ChaCha20 - Poly1305 cipher suite from start . Probably with SHA-256 . X25519 and EdDSA.The CNSA cipher suite does not really need a 1 byte value . Could live with 2 byte value . 
 -Agreement during interim is that the 4 different CCM are all needed and that they are the correct ones . -ChaCha20 should be combined with both P-256 and X25519 -CNSA suite can have two bytes . 
 I think we should specify a X448 / SHAKE256 suite to complement the CNSA suite . 
 The GCM suite is chosen to match what is currently used on the web which is X25519 combined with P-256 ECDSA . Not sure we need to specify anything else here . IoT community seems more interested in ChaCha20 than GCM . ~~ 
 Resolved with .
Paragraph (version A):
The following cipher suite is for high security application such as
government use and financial applications.  It is compatible with the
CNSA suite CNSA.
Paragraph (version B):
The following ChaCha20 cipher suites are for less constrained
applications and only use 128-bit tag lengths.
Paragraph (version B):
The following two cipher suites are for high security application
such as government use and financial applications.  The two cipher
suites do not share any algorithms.  The first of the two cipher
suites is compatible with the CNSA suite CNSA.
Draft: draft-ietf-lake-edhoc

Commentary: Discussion today in COSE on how to do RPK by value in EDHOC . Suggestions to send a COSE_Key or a C509 . Additional suggestion from Carsten to use CWT . Several issues in the old GitHub on CWTs , that were not transfered to the new GitHub : Discussion to transfer CWT in kid , in Auxilery data , and as COSE header parameter . Transfering CWT is related to issues , , , 
 I made a pull request for this I think it is essential that EDHOC supports CWT . CWTs are much more flexible than X.509 / C.509 . I think both are needed . The need for CWT has been discussed since 2016 . I think it was decided clear quite early that transporting CWT is needed but was a discussion on how to transfer them . In Aux Data , in COSE header parameter , or in the kid bstr . For some reason nothing was ever specified . TLS WG is discussing to add support for CWT . I think certificates and CWT needs to be included , I am not sure that we need a different format for RPK . Likely CWT or C509 can be used for this purpose . 
 I think it should be discussed if CWT is good enough for the . My initial understanding is that it is but this needs to be analyzed and discussed . My current thoughts . CWT needs to be supported in EDHOC . Most things in CWT is optional , it is likely an optimized enough format for the oportunistic / TOFU use case of " RPK " . CWT is also very flexible . When CWT exist it would be strange to standardize a new format for transfereing a COSEKey unless it is really really needed to save bytes . CWT + Deterministic CBOR could maybe replace the discussion on how to integrity protect COSEKeys . We should at least remove the new subjectname from the COSEKey part in the EDHOC document . CWT and C509 can be used when subject name is needed . Does " Raw " COSE_Keys that are not CWT even need to be supported ? Or would CWT / C509 / X.509 be enough 
 This change has now been done in the master branch , see and commits in its vicinity . Can we close the issue ? 
 This has now been addressed .
Paragraph (version B):
This document registers the following entries in the "COSE Header
Parameters" registry under the "CBOR Object Signing and Encryption
(COSE)" heading.  The value of the 'cwt' header parameter is a CWT
RFC8392 or an unprotected CWT Claims Set I-D.ietf-rats-uccs.
Draft: draft-ietf-lake-edhoc

Commentary: This addresses . I do n't think we need to include names for the intermediary hashes .
Paragraph (version A):
Compute the transcript hash TH_2 = H(message_1, data_2) where H()
is the hash function in the selected cipher suite.  The transcript
hash TH_2 is a CBOR encoded bstr and the input to the hash
function is a CBOR Sequence.
Paragraph (version B):
Compute the transcript hash TH_2 = H( H(message_1), data_2 ) where
H() is the hash function in the selected cipher suite.  The
transcript hash TH_2 is a CBOR encoded bstr and the input to the
hash function is a CBOR Sequence.  Note that H(message_1) can be
computed and cached alredy in the processing of message_1.
Paragraph (version A):
Compute the transcript hash TH_3 = H(TH_2 , CIPHERTEXT_2, data_3)
where H() is the hash function in the selected cipher suite.  The
transcript hash TH_3 is a CBOR encoded bstr and the input to the
hash function is a CBOR Sequence.
Paragraph (version B):
Compute the transcript hash TH_3 = H( H(TH_2, CIPHERTEXT_2),
data_3 ) where H() is the hash function in the selected cipher
suite.  The transcript hash TH_3 is a CBOR encoded bstr and the
input to the hash function is a CBOR Sequence.  Note that H(TH_2,
CIPHERTEXT_2) can be computed and cached alredy in the processing
of message_2.
Draft: draft-ietf-lake-edhoc

Commentary: When the responder is processing message 1 , section 4.4.3 reads : If any verification step fails , the Initiator MUST send an EDHOC error message back , formatted as defined in Section 5 , and the protocol MUST be discontinued . I think this should be : If any verification step fails , the MUST send an EDHOC error message back , formatted as defined in Section 5 , and the protocol MUST be discontinued . PR :
Paragraph (version A):
If any verification step fails, the Initiator MUST send an EDHOC
error message back, formatted as defined in error, and the protocol
MUST be discontinued.  If the Responder does not support the selected
cipher suite, then SUITES_R MUST include one or more supported cipher
suites.  If the Responder does not support the selected cipher suite,
but supports another cipher suite in SUITES_I, then SUITES_R MUST
include the first supported cipher suite in SUITES_I.
Paragraph (version B):
If any verification step fails, the Responder MUST send an EDHOC
error message back, formatted as defined in error, and the protocol
MUST be discontinued.  If the Responder does not support the selected
cipher suite, then SUITES_R MUST include one or more supported cipher
suites.  If the Responder does not support the selected cipher suite,
but supports another cipher suite in SUITES_I, then SUITES_R MUST
include the first supported cipher suite in SUITES_I.