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

Commentary: using the same key for Initiator and Responder 
 The document need to say something about this . It seems very uncontroversial to state that it MAY be used for both . I think this can be merged and the issue closed . 
 Proposal : OLD " The same authentication key MAY be used for both the Initiator and Responder roles . " NEW " The same authentication credential MAY be used for both the Initiator and Responder roles . "
Paragraph (version A):
As noted in Section 12 of RFC9052 the use of a single key for
multiple algorithms is strongly discouraged unless proven secure by a
dedicated cryptographic analysis.  In particular this recommendation
applies to using the same private key for static Diffie-Hellman
authentication and digital signature authentication.  A preliminary
conjecture is that a minor change to EDHOC may be sufficient to fit
the analysis of secure shared signature and ECDH key usage in
Degabriele11 and Thormarker21.
Paragraph (version B):
The same authentication credential MAY be used for both the Initiator
and Responder roles.  As noted in Section 12 of RFC9052 the use of a
single key for multiple algorithms is strongly discouraged unless
proven secure by a dedicated cryptographic analysis.  In particular
this recommendation applies to using the same private key for static
Diffie-Hellman authentication and digital signature authentication.
A preliminary conjecture is that a minor change to EDHOC may be
sufficient to fit the analysis of secure shared signature and ECDH
key usage in Degabriele11 and Thormarker21.
Draft: draft-ietf-lake-edhoc

Commentary: Adding two further analyses that contributed to EDHOC ( ): Cottier , Pointcheval : " Security Analysis of the EDHOC protocol " . Sep 2022 . Günther , Ilunga : " Careful with MAc - then - SIGn : A Computational Analysis of the EDHOC Lightweight Authenticated Key Exchange Protocol " . Dec 2022 . 
 Given the various security analyses EDHOC has seen and their insights being discussed in Section 8 , would it make sense to add informative references to those ( as done , e.g. , for TLS 1.3 , RFC 8446 Appendix E ) ? 
 Seems like a good idea to me 
 Related to 
 This was discussed on the IETF 116 LAKE WG meeting , and in absence of volunteers to draft such an appendix we decided to start with adding references . We may want to go somewhere in between a whole appendix and a sentence , and expand with a paragraph about each reference . We still need someone to draft that paragraph for the different references and would like to conclude on this fairly soon . We start by merging now . 
 Closing since is merged .
Mailing list commentary: Hi all , While we do not have any explicit comments on the document , we thought it is maybe still worthwhile to share the following analysis confirmation . We updated our computational analysis of the SIG - SIG mode , of which presented an earlier version at IETF 114 , to draft 17 . We could confirm that with some of the later cryptographic suggestions ( PR # 276 , # 318 ) included , EDHOC SIG - SIG achieves key exchange security ( key secrecy and explicit authentication ) in a strong model capturing potentially colliding credential identifiers , assuming , among others , an " exclusive ownership " property of the signature scheme ( established for Ed25519 , conjectured for the way ECDSA is used in EDHOC SIG - SIG ) . Our updated analysis is not publicly available yet at this point . Let us know if a public reference would be helpful for the draft RFC ; we can also share the document individually upon request . The last point actually maybe does lead to a comment on the document : Given the various security analyses EDHOC has seen and their insights being discussed in Section 8 , would it make sense to add informative references to those ( as done , e.g. , for TLS 1.3 , RFC 8446 Appendix E ) ? Kind regards , ( with )
Paragraph (version A):
Earlier versions of EDHOC have been formally analyzed Jacomme23
Norrman20 Bruni18 and the specification has been updated based on the
analysis.
Paragraph (version B):
Earlier versions of EDHOC have been formally analyzed Bruni18
Norrman20 CottierPointcheval22 Jacomme23 GuentherIlunga22 and the
specification has been updated based on the analysis.
Draft: draft-ietf-lake-edhoc

Commentary: First take on explaining how to calculate a Y value for old APIs not supporting the full { { SECG } } format . 
 Given e.g. the Julia programming language the calculations aretrivial For more constrained platforms maybe we should have some link to a paper explaining how to do this type of calculations on constrained platforms . file:///Users / emanjon / Downloads / applsci-10- 
 If a y - coordinate is required then the value ~yp SHALL be set to zero This leads to unnecesary extra code if a y value is calculated . I suggest that we reformulate this 
   wrote me that RFC 6090 Appendix C is a good high level reference for this . 
 LGTM 
 and others : is the new text sufficient to support implementers which has to use a library requiring the y - coordinate ? 
 Merged PR to master that addresses this 
 Here some comments after going through the PR .
Paragraph (version A):
The ephemeral public keys in EDHOC (G_X and G_Y) use compact
representation of elliptic curve points, see comrep.  In COSE compact
representation is achieved by formatting the ECDH ephemeral public
keys as COSE_Keys of type EC2 or OKP according to Sections 7.1 and
For Elliptic Curve Keys of type EC2, compact representation MAY be
used also in the COSE_Key.  If the COSE implementation requires a 'y'
parameter, the value y = false SHALL be used.  COSE always use
compact output for Elliptic Curve Keys of type EC2.
Paragraph (version B):
The ephemeral public keys in EDHOC (G_X and G_Y) use compact
representation of elliptic curve points, see comrep.  In COSE compact
representation is achieved by formatting the ECDH ephemeral public
keys as COSE_Keys of type EC2 or OKP according to Sections 7.1 and
For Elliptic Curve Keys of type EC2, compact representation MAY be
used also in the COSE_Key.  COSE always uses compact output for
Elliptic Curve Keys of type EC2.  If the COSE implementation requires
a 'y' parameter, the value y = false or a calculated y-coordinate can
be used, see comrep.
Draft: draft-ietf-lake-edhoc

Commentary: This note needs to be updated . The sentence is a remnant since  was defined as H(TH2 , PLAINTEXT_2 )
Paragraph (version A):
Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2, CRED_R)
where H() is the EDHOC hash algorithm of 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,
PLAINTEXT_2) can be computed and cached already in the processing
of message_2.
Paragraph (version B):
Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2, CRED_R)
where H() is the EDHOC hash algorithm of 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 TH_3 can
be computed and cached already in the processing of message_2.
Paragraph (version A):
Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I)
where H() is the EDHOC hash algorithm of the selected cipher
suite.  The transcript hash TH_4 is a CBOR encoded bstr and the
input to the hash function is a CBOR Sequence.
Paragraph (version B):
Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I)
where H() is the EDHOC hash algorithm of the selected cipher
suite.  The transcript hash TH_4 is a CBOR encoded bstr and the
input to the hash function is a CBOR Sequence.  Note that TH_4 can
be computed and cached already in the processing of message_3.
Draft: draft-ietf-lake-edhoc

Commentary: Do you or  have any comment on the formulation ? 
 We needed to merge this PR to prepare for -17 , but we are of course still interested in your comments :-) 
 No comment to do ;) . It 's good . 
 This is the outcome of the work by Baptiste  and   related to The conclusions form  and  is that after receiving message4 the Initiator has authenticated the Responder with a strength of the combined MACs in message2 and  . I.e. if both MACs are 64 bits , they work together as a 128 bit MAC . The same thing apply to application messages such as OSCORE used as message 4,5,6 , ..... but this comes with the additional requirement that the security association has to be terminated and EDHOC redone in the case that verification of the OSCORE MAC fails . The same apply to the draft - ietf - core - oscore - edhoc where 2 MACs are sent in flight 3 The same priciple should apply to modes with signatures where a signature in message2 combined with a MAC in message_4 gives the strenght of the signature and the MAC combined . Baptiste and  have not investigated this formally . 
 Good . Terminology comment : You use first " authenticated with 128 - bit security " and then " 128 - bit mutual authentication " . I assume that means the same in security terms ( although one is unilateral and the other mutual ) . No mentioning of online attacks here . Is it clear how that relates to " 64 - bit security against online brute force attacks " which is stated in another security consideration ? " can be achieved after verification of the first OSCORE Response " . This is correct in its brevity , but the use of " verification " gives the impression that it is the verification of OSCORE Response is what makes this achieved , rather than it is the completion of the processing of the OSCORE request and OSCORE response that are the moments in time when , with the appropriate measures , security can be achieved . Perhaps replace " verification " with " completion " .
Paragraph (version B):
As the EDHOC protocol is terminated when verification fails, the
security against online attacks is given by the sum of the strength
of the verified signatures, MACs (including MAC in AEAD).  As an
example, if EDHOC is used with method 3, cipher suite 2, and
message_4, the Responder is authenticated with 128-bit security
against online attacks (the sum of the 64-bit MACs in message_2 and
message_4).  The same principle applies for MACs in an application
protocol keyed by EDHOC as long as EDHOC is rerun when verification
of the first MACs in the application protocol fail.  As an example,
if EDHOC with method 3 and cipher suite 2 is used as in Figure 2 of
I-D.ietf-core-oscore-edhoc, 128-bit mutual authentication against
online attacks can be achieved after completion of the first OSCORE
request and response.
Draft: draft-ietf-lake-edhoc

Commentary: Suggestion to clarify and maybe give example of randomness and unpredictability . The SHOULD should probably be removed . Unclear if 1 byte identifiers can ever by unpredictable . 
 Closing this as approved by  . 
 Looks good to me . ?
Paragraph (version A):
An attacker observing network traffic may use connection identifiers
sent in clear in EDHOC or the subsequent application protocol to
correlate packets sent on different paths or at different times.  The
attacker may use this information for traffic flow analysis or to
track an endpoint.  Application protocols using connection
identifiers from EDHOC SHOULD provide mechanisms to update the
connection identifier and MAY provide mechanisms to issue several
simultaneously active connection identifiers.  See RFC9000 for a non-
constrained example of such mechanisms.  Connection identifiers
SHOULD be unpredictable.  Using the same identifier several times is
not a problem as long as it is chosen randomly.  Connection identity
privacy mechanisms are only useful when there are not fixed
identifiers such as IP address or MAC address in the lower layers.
Paragraph (version B):
An attacker observing network traffic may use connection identifiers
sent in clear in EDHOC or the subsequent application protocol to
correlate packets sent on different paths or at different times.  The
attacker may use this information for traffic flow analysis or to
track an endpoint.  Application protocols using connection
identifiers from EDHOC SHOULD provide mechanisms to update the
connection identifier and MAY provide mechanisms to issue several
simultaneously active connection identifiers.  See RFC9000 for a non-
constrained example of such mechanisms.  Connection identifiers can
e.g., be chosen randomly among the set of unused 1-byte connection
identifiers.  Connection identity privacy mechanisms are only useful
when there are not fixed identifiers such as IP address or MAC
address in the lower layers.
Draft: draft-ietf-lake-traces

Commentary: Merging in preparation for submission .
Paragraph (version A):
Section 3.  Authentication with signature keys identified by the
hash value of the X.509 certificates (provided in certs).  The
endpoints use EdDSA RFC8032 for authentication and X25519 RFC7748
for ephemeral-ephemeral Diffie-Hellman key exchange.
Paragraph (version A):
Section 4.  Authentication with static Diffie-Hellman keys
identified by short key identifiers labelling CWT Claim Sets
(CCSs) RFC8392.  The endpoints use NIST P-256 (FIPS PUB 186-4) for
both ephemeral-ephemeral and static-ephemeral Diffie-Hellman key
exchange.  This trace also illustrates the cipher suite
negotiation, and provides an example of low protocol overhead,
with messages sizes of (39, 45, 19) bytes.
Paragraph (version B):
sec-trace-1 - Authentication with signature keys identified by the
hash value of the X.509 certificates (provided in certs).  The
endpoints use EdDSA RFC8032 for authentication and X25519 RFC7748
for ephemeral-ephemeral Diffie-Hellman key exchange.
Paragraph (version B):
sec-trace-2 - Authentication with static Diffie-Hellman keys
identified by short key identifiers labelling CWT Claim Sets
(CCSs) RFC8392.  The endpoints use NIST P-256 (FIPS PUB 186-4) for
both ephemeral-ephemeral and static-ephemeral Diffie-Hellman key
exchange.  This trace also illustrates the cipher suite
negotiation, and provides an example of low protocol overhead,
with messages sizes of (39, 45, 19) bytes.
Paragraph (version A):
The traces in this draft are valid for version -14 and -15 of I-
D.ietf-lake-edhoc.
Paragraph (version B):
The traces in this draft are valid for version -17 of I-D.ietf-lake-
edhoc.
Paragraph (version A):
NOTE 3.  When the protocol transporting EDHOC messages does not
inherently provide correlation across all messages, like CoAP, then
some messages typically are prepended with connection identifiers and
potentially a message_1 indicator (see Section 3.4.1 and Appendix A.3
of I-D.ietf-lake-edhoc).  Those bytes are not included in the traces
in this document.
Paragraph (version B):
NOTE 3.  When the protocol transporting EDHOC messages does not
inherently provide correlation across all messages, like CoAP, then
some messages typically are prepended with connection identifiers and
potentially a message_1 indicator (see Sections 3.4.1 and A.2 of I-
D.ietf-lake-edhoc).  Those bytes are not included in the traces in
this document.
Paragraph (version A):
Key update is defined in Section 4.2.2 of I-D.ietf-lake-edhoc.
Paragraph (version A):
ey update is defined in Section 4.2.2 of I-D.ietf-lake-edhoc.
Draft: draft-ietf-lake-edhoc

Commentary: . First text based on initial draft by Christian . 
 On request . Some people have already implemented this and may want to comment on the Implementation Note in PR . 
 Merged
Paragraph (version B):
Implementation Note: When implementing the byte string identifier
representation it can in some programming languages help to define a
new type, or other data structure, which (in its user facing API)
behaves like a byte string, but when serializing to CBOR produces a
byte string or an integer depending on its value.
Draft: draft-ietf-lake-edhoc

Commentary: Based on side comment in about " all symmetric keys are derived using as much previous information as possible "
Paragraph (version A):
EDHOC is designed to encrypt and integrity protect as much
information as possible, and all symmetric keys are derived using as
much previous information as possible.  EDHOC is furthermore designed
to be as compact and lightweight as possible, in terms of message
sizes, processing, and the ability to reuse already existing CBOR,
COSE, and CoAP libraries.  Like (D)TLS, authentication is the
responsibility of the application, EDHOC identifies (and optionally
transports) authentication credentials, and provides proof-of-
possession of the private authentication key.
Paragraph (version B):
EDHOC is designed to encrypt and integrity protect as much
information as possible.  Symmetric keys and random material derived
using EDHOC-KDF are derived with as much previous information as
possible, see fig-edhoc-kdf.  EDHOC is furthermore designed to be as
compact and lightweight as possible, in terms of message sizes,
processing, and the ability to reuse already existing CBOR, COSE, and
CoAP libraries.  Like (D)TLS, authentication is the responsibility of
the application, EDHOC identifies (and optionally transports)
authentication credentials, and provides proof-of-possession of the
private authentication key.
Draft: draft-ietf-lake-edhoc

Commentary: The current text just says that : " The Initiator and the Responder must make sure that unprotected data and  do not reveal any sensitive information . This also applies for encrypted data sent to an unauthenticated party . In particular , it applies to EAD1 , IDCREDR , EAD2 , and error messages . " The eadvalue is expected to sometimes / often be encrypted outside of EDHOC . The text should be augmented with text that eadlabel leaks information even if ead_value is encrypted outside of EDHOC .
Paragraph (version A):
The Initiator and the Responder must make sure that unprotected data
and metadata do not reveal any sensitive information.  This also
applies for encrypted data sent to an unauthenticated party.  In
particular, it applies to EAD_1, ID_CRED_R, EAD_2, and error
messages.  Using the same EAD_1 in several EDHOC sessions allows
passive eavesdroppers to correlate the different sessions.  Another
consideration is that the list of supported cipher suites may
potentially be used to identify the application.  The Initiator and
the Responder must also make sure that unauthenticated data does not
trigger any harmful actions.  In particular, this applies to EAD_1
and error messages.
Paragraph (version B):
The Initiator and the Responder must make sure that unprotected data
and metadata do not reveal any sensitive information.  This also
applies for encrypted data sent to an unauthenticated party.  In
particular, it applies to EAD_1, ID_CRED_R, EAD_2, and error
messages.  Using the same EAD_1 in several EDHOC sessions allows
passive eavesdroppers to correlate the different sessions.  Note that
even if ead_value is encrypted outside of EDHOC, the ead_label in
EAD_1 is revealed to passive attackers and the ead_label in EAD_2 is
revealed to active attackers.  Another consideration is that the list
of supported cipher suites may potentially be used to identify the
application.  The Initiator and the Responder must also make sure
that unauthenticated data does not trigger any harmful actions.  In
particular, this applies to EAD_1 and error messages.
Draft: draft-ietf-lake-edhoc

Commentary: There are now two different media types defined . Padding was missing from the list that EDHOC adds .
Paragraph (version A):
Method types and error handling.
Paragraph (version B):
Method types, error handling, and padding.
Paragraph (version A):
Application data may be protected using the agreed application
algorithms (AEAD, hash) in the selected cipher suite (see cs) and the
application can make use of the established connection identifiers
C_I and C_R (see ci).  EDHOC may be used with the media type
application/edhoc+cbor-seq defined in media-type.
Paragraph (version B):
Application data may be protected using the agreed application
algorithms (AEAD, hash) in the selected cipher suite (see cs) and the
application can make use of the established connection identifiers
C_I and C_R (see ci).  Media types that may be used for EDHOC are
defined in media-type.
Draft: draft-ietf-lake-edhoc

Commentary: This is an editorial change . 
 If there is a risk someone thinks that padding in the messages must be the same we could use PAD2 , PAD3 , PAD_4 . 
 If I understand correctly , the PAD is to hide the length of the messages . If the three messages share the same PAD length , it is enough for one of the message to have a length known by the attacker , e.g. if EAD_4 is of constant length across all sessions , to leak the length of the PAD , and thus the length of the other messages contents . As such , 3 distinct padding lengths would be strictly better . Otherwise , as the encryptions are distinct ( different key streams ) , I on my side do n't see any weird cryptographic interactions that would be possible . ( a side question is does the padding in message 2 leads to potential for padding oracles attacks , where the attacker could try to flip a few bytes of the cyphertext and learn some information based on which step of the processing fail . However , that is covered by I guess ) 
 This is an editorial change . I merged the PR and will close this issue . No and yes . SIGMA and EDHOC and TLS 1.3 does not provide confidentiality of the second flight to active attackers ( except maybe the signature ) . In SIGMA and EDHOC and attacker can modify the second flight and gain information . But this attack seems very uninteresting compared to attacks where the attacker modifies message_1 .
Paragraph (version A):
Decrypt CIPHERTEXT_2, see asym-msg2-proc, and, if present, discard
padding.
Paragraph (version B):
Decrypt CIPHERTEXT_2, see asym-msg2-proc, and, if present, discard
the padding PAD_2.
Paragraph (version A):
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD
algorithm in the selected cipher suite, and the parameters defined
in asym-msg3-proc.  Discard padding, if present.
Paragraph (version B):
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD
algorithm in the selected cipher suite, and the parameters defined
in asym-msg3-proc.  Discard the padding PAD_3, if present.
Paragraph (version A):
PAD = 1* "true" (see CBOR) is padding that may be used to
hide the length of the unpadded plaintext.
Paragraph (version B):
PAD_4 = 1* "true" (see CBOR) is padding that may be used to
hide the length of the unpadded plaintext.
Paragraph (version A):
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD
algorithm in the selected cipher suite, and the parameters defined
in asym-msg4-proc.  Discard padding, if present.
Paragraph (version B):
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD
algorithm in the selected cipher suite, and the parameters defined
in asym-msg4-proc.  Discard the padding PAD_4, if present.