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

Commentary: Some additional text on connection i d privacy New connections identifiers needs to be unpredictable to provide improved privacy QUIC requirement to not use the same identifier in a connection seems like nonsense that lowers privacy compared to random selection and increases implementation complexity . Christian Amsuss pointed out in a discussion in CORE that connection i d privacy often does not make sense in many deployments as there are fixed identifier in lower layers 
 LGTM 
 If connection identifiers are predictable ( e.g. , a sequence ) they might be used by an attacker to determine that the two EDHOC sessions came from the same device . We should add a sentence on this . In practice it does not matter unless IP address , MAC address , etc are randomized as well . 
 Isn´t it covered by sec 8.5 ? : Essentially , any of the additional data (  and CI / CR ) can be used to attack privacy , whether anonymity or unlinkability . A side remark is that even with padding , if any of the EADs is a counter , the length of messagex can allow to distinguish high intensity traffic vs low intensity traffic . 
 Yes , it does . The text is more general then I thought . Should probablt have some guidance on non - predictable connection identifiers . If a device is using a sequence like 0x3489f2 , 0x3489f3 , 0x3489f4 , 0x3489f5 updating the connection identifier is quite useless .
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.
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
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.
Draft: draft-ietf-lake-edhoc

Commentary: Based on comments by
Paragraph (version A):
ID_CRED_x = { 4 : key_id_x }, where key_id_x : kid, for x = I or
R.
Paragraph (version A):
The value of a COSE 'kid' parameter is a byte string.  To allow one-
byte encodings of ID_CRED_x with key identifiers 'kid', which is
useful in scenarios with only a few keys, the integer representation
of identifiers in bstr-repr MUST be applied.  For details, see asym-
msg2-proc and asym-msg3-proc.
Paragraph (version B):
ID_CRED_x = { 4 : kid_x }, where kid_x : kid, for x = I or R.
Paragraph (version B):
The value of a COSE 'kid' parameter is a CBOR byte string.  For a
more compact representation, the CBOR map is replaced by a byte
string, see the definitions of plaintext in asym-msg2-proc and asym-
msg3-proc.  To allow one-byte encodings of ID_CRED_x with key
identifiers 'kid' the integer representation of byte string
identifiers in bstr-repr MUST be applied.
Paragraph (version B):
The CBOR map { 4 : h'FF' } is not encoded as 0xA10441FF but as the
CBOR byte string h'FF', i.e. 0x41FF.
Paragraph (version B):
The CBOR map { 4 : h'21' } is neither encoded as 0xA1044121, nor
as the CBOR byte string h'21', i.e. 0x4121, but as the CBOR
integer 0x21.
Paragraph (version A):
If ID_CRED_R contains a single 'kid' parameter, i.e.,
ID_CRED_R = { 4 : kid_R }, then only the byte string kid_R
is conveyed in the plaintext, represented as described in
bstr-repr.
Paragraph (version B):
If ID_CRED_R contains a single 'kid' parameter, i.e.,
ID_CRED_R = { 4 : kid_R }, then only the byte string is
included in the plaintext, represented as described in bstr-
repr, see examples in id_cred.
Paragraph (version A):
If ID_CRED_I contains a single 'kid' parameter, i.e.,
ID_CRED_I = { 4 : kid_I }, then only the byte string kid_I
is conveyed in the plaintext, represented as described in
bstr-repr.
Paragraph (version B):
If ID_CRED_I contains a single 'kid' parameter, i.e.,
ID_CRED_I = { 4 : kid_I }, then only the byte string is
included in the plaintext, represented as described in bstr-
repr, see examples in id_cred.
Draft: draft-ietf-lake-edhoc

Commentary: Reformulating security of expand as stream cipher instead of removing . HKDF - Expand is very often used . Added note of HKDF - Expand length restriction . Key use for different algorithms is already covered by COSE . Nothing is special with use inside of EDHOC . The text is clearly not correct at as signate can also be used in other methods . 
 Channeling from  . Use of the HKDF as EDHOC - KDF for generation of  and encryption of message2 induces a  size . For example , HKDF - SHA256 has  output size 255 * 32 = 8160 bytes .
Paragraph (version A):
As discussed in SIGMA, the encryption of message_2 does only need to
protect against passive attacker as active attackers can always get
the Responder's identity by sending their own message_1.  EDHOC uses
the Expand function (typically HKDF-Expand) as a binary additive
stream cipher.  HKDF-Expand is not often used as it is slow on long
messages, and most applications require both IND-CCA confidentiality
as well as integrity protection.  For the encryption of message_2,
any speed difference is negligible, IND-CCA does not increase
security, and integrity is provided by the inner MAC (and signature
depending on method).
Paragraph (version B):
As discussed in SIGMA, the encryption of message_2 does only need to
protect against passive attacker as active attackers can always get
the Responder's identity by sending their own message_1.  EDHOC uses
the Expand function (typically HKDF-Expand) as a binary additive
stream cipher which is proven secure as long as the expand function
is a PRF.  HKDF-Expand is not often used as a stream cipher as it is
slow on long messages, and most applications require both IND-CCA
confidentiality as well as integrity protection.  For the encryption
of message_2, any speed difference is negligible, IND-CCA does not
increase security, and integrity is provided by the inner MAC (and
signature depending on method).
Paragraph (version A):
A static Diffie-Hellman key for authentication in method 1, 2 or 3
MUST NOT not be used as a digital signature key for authentication in
method 0, unless proven secure by a dedicated cryptographic analysis.
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):
As noted in Section 12 of I-D.ietf-cose-rfc8152bis-struct the use of
a single key for multiple algorithms is strongly disencouraged 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):
Note that HKDF-Expand has a relativly small maximum output length of
255 * hash_length.  This means that when when SHA-256 is used as hash
algorithm, message_2 cannot be longer than 8160 bytes.
Draft: draft-ietf-lake-edhoc

Commentary: A static key should not be used both for X25519 and Ed25519 . This PR corresponds to . 
 Please review the proposed change . 
 The standard does not restrict private key usages . In particular , it could be tempting to use the public / private keys for the signature scheme as a public and private key pair for the static authentication mode with the elliptic curve X25519 . This does not have clear direct and practical implications . However , this usage falls outside the existing cryptanalysis for the signature scheme , and is a bad practice from a theoretical point of view . This would require a dedicated cryptographic analysis , similar to [ 2 ] . [ 1 , Section 12 ] typically recommends that different keys are used for different algorithms , but it may be unclear if the EDHOC use case falls under this recommandation , or if an extra one could be pertinent . We recommend to mention this issue somewhere in the standard , or explicitly forbid such a shared key usage . [ 1 ] : [ 2 ] : On using the same key pair for Ed25519 and an X25519 based KEM .   . 
 I 've seen single keys used for both and x25519 during plugtests ; IIUC the agreement among the plugtesters back then was that this was not intended use and should generally not be done . This might serve as a data point that illustrates the need for a clear statement . 
 Mentioning this issue and refering to [ 1 , Section 12 ] seems like a good idea . The text would need to mention EDHOC methods as [ 1 , Section 12 ] only talks about algorithms and the ECDHE in EDHOC is not strictly a COSE algorithm . Writing that using the same key requires a dedicated cryptographic analysis , similar to [ 2 ] also seems like a good idea . ( As a comparision , I do n't think TLS 1.3 states anything about forbidding the public key in the certificate to be used for  , ECIES , or ECDHE outside of TLS ) . 
 Should we propose a PR for this ? 
 Please go ahead . Prepare for the option to have a reference to an analysis showing this is secure under certain conditions .
Paragraph (version B):
A static Diffie-Hellman key for authentication in method 1, 2 or 3
MUST NOT not be used as a digital signature key for authentication in
method 0, unless proven secure by a dedicated cryptographic analysis.
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 [Degabriele2011] and .
Draft: draft-ietf-lake-edhoc

Commentary: Signed - off - by :   
 and others : Any response to  's comment ? 
 I included  's suggestion in the PR . 
 Looks good to me . Other opinions ? 
 As specified in section , the payload in some CoAP messages can be an EDHOC message prepended by either a C_x identifier or " true " . The draft states : However , the payload is actually a CBOR Sequence as defined by . Thus , we could define and use a new media type " application / edhoc+cbor - seq " . Note that the usage of the Content - Format option is optional . 
 Makes sense to me . others : Comments ? Good that you bring up the optionality of Content - Format , we should stress that in this text . The discussion in Hackathon also reminded me about the common - option - compression which presented in the May 12 interim 2021 - how to replace the Uri - Path : " /.well - known / edhoc " with a , say , integer valued CoAP option . 
 Makes a lot of sense to me , too . 
 I find this distinction good and the solution consequential , still open for comments .
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 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).  EDHOC may be used with the media type
application/edhoc+cbor-seq defined in media-type.
Paragraph (version A):
IANA has added the media type "application/edhoc" to the "Media
Types" registry.
Paragraph (version B):
IANA has added the media types "application/edhoc+cbor-seq" and
"application/cid-edhoc+cbor-seq" to the "Media Types" registry.
Paragraph (version A):
IANA has added the media type "application/edhoc" to the "CoAP
Content-Formats" registry under the group name "Constrained RESTful
Environments (CoRE) Parameters".
Paragraph (version B):
Security considerations: See Section 7 of this document.
Paragraph (version B):
Person & email address to contact for further information: See
"Authors' Addresses" section.
Paragraph (version B):
Author: See "Authors' Addresses" section.
Paragraph (version B):
IANA has added the media types "application/edhoc+cbor-seq" and
"application/cid-edhoc+cbor-seq" to the "CoAP Content-Formats"
registry under the group name "Constrained RESTful Environments
(CoRE) Parameters".
Draft: draft-ietf-lake-edhoc

Commentary: In PR statements about expected limitations in crypto support was lost . Now moved to security considerations .
Paragraph (version A):
If ECDSA is supported, "deterministic ECDSA" as specified in RFC6979
MAY be used.  Pure deterministic elliptic-curve signatures such as
deterministic ECDSA and EdDSA have gained popularity over randomized
ECDSA as their security do not depend on a source of high-quality
randomness.  Recent research has however found that implementations
of these signature algorithms may be vulnerable to certain side-
channel and fault injection attacks due to their determinism.  See
e.g., Section 1 of I-D.mattsson-cfrg-det-sigs-with-noise for a list
of attack papers.  As suggested in Section 6.1.2 of I-D.ietf-cose-
rfc8152bis-algs this can be addressed by combining randomness and
determinism.
Paragraph (version B):
For many constrained IoT devices it is problematic to support several
crypto primitives.  Existing devices can be expected to support
either ECDSA or EdDSA.  If ECDSA is supported, "deterministic ECDSA"
as specified in RFC6979 MAY be used.  Pure deterministic elliptic-
curve signatures such as deterministic ECDSA and EdDSA have gained
popularity over randomized ECDSA as their security do not depend on a
source of high-quality randomness.  Recent research has however found
that implementations of these signature algorithms may be vulnerable
to certain side-channel and fault injection attacks due to their
determinism.  See e.g., Section 1 of I-D.mattsson-cfrg-det-sigs-with-
noise for a list of attack papers.  As suggested in Section 6.1.2 of
I-D.ietf-cose-rfc8152bis-algs this can be addressed by combining
randomness and determinism.
Draft: draft-ietf-lake-edhoc

Commentary: Good to describe that the known attack on Sigma is that the attacker create a new message_1 , no attack is known where an active attacker modifies the ongoing connection ( even if the lack of such attacks is likely not proven ) . 
 This seems ready to merge 
 Current draft says : " EDHOC protects the credential identifier of the Initiator against active attacks and the credential identifier of the Responder against passive attacks . " Should probably point out that active attack would be a new message1 to the lower layer address as the other message1 .
Paragraph (version A):
As described in SIGMA, different levels of identity protection are
provided to the Initiator and the Responder.  EDHOC protects the
credential identifier of the Initiator against active attacks and the
credential identifier of the Responder against passive attacks.  The
roles should be assigned to protect the most sensitive identity/
identifier, typically that which is not possible to infer from
routing information in the lower layers.
Paragraph (version B):
As described in SIGMA, different levels of identity protection are
provided to the Initiator and the Responder.  EDHOC protects the
credential identifier of the Initiator against active attacks and the
credential identifier of the Responder against passive attacks.  An
active attacker can get the credential identifier of the Responder by
eavesdropping on the destination address used for transporting
message_1 and send its own message_1 to the same address.  The roles
should be assigned to protect the most sensitive identity/identifier,
typically that which is not possible to infer from routing
information in the lower layers.
Draft: draft-ietf-lake-edhoc

Commentary: I think this can be merged . 
 Fixed the problem with ' : ' in refs . Now merging . 
 Based on  review 
 Referring to this in : 
 From the PR : " As explained by Krawczyk , any attack mitigated by the NIST requiment would mean that the KDF is fully broken and would have to be replaced anyway . " I did n't understand " any attack mitigated by the NIST requirement " , and how mitigation could imply that something is broken . As far as I understand , the statement is something like " if there is a problem deriving secret and non - secret material from the same KDF , then there is a problem with the KDF " Perhaps " an attack based on the violation of the NIST requirement is an attack on the KDF itself " ? 
 Yes , it was likely meants to say " if any attack is mitigate " Let 's reformulate according to your suggestion 
 I made a commit to correct spelling and grammar . I do n't think we can give applications more guidance here . How to gererate e.g. private key in certificates are way outside of EDHOC , and it would anyway be hard to say something general as deployments might look very different . I did not want to say anything about randomly generated conenction ID as that is not how connection IDs is meant to be generated . They are intended to be as short as possible . An implentation is allowed to use long random bytestrings but is not recommended in general . 
 PR merged
Paragraph (version B):
Implementations might consider deriving secret and non-secret
randomness from different PNRG/PRF/KDF instances to limit the damage
if the PNRG/PRF/KDF turns out to be fundamentally broken.  NIST
generally forbids deriving secret and non-secret randomness from the
same KDF instance, but this decision has been criticized by Krawczyk
HKDFpaper and doing so is common practice.  In addition to IVs, other
examples are the challenge in EAP-TTLS, the RAND in 3GPP AKAs, and
the Session-Id in EAP-TLS 1.3.  Note that part of KEYSTREAM_2 is also
non-secret randomness as it is known or predictable to an attacker.
As explained by Krawczyk, if any attack is mitigated by the NIST
requirement it would mean that the KDF is fully broken and would have
to be replaced anyway.
Draft: draft-ietf-lake-edhoc

Commentary: From Sean 's review : s5.1 ( question ): Is a state diagram needed ? One thing people clamored for from TLS was a state machine . Maybe a diagram is n’t needed because there are so few states ? 
 Not sure it is needed in EDHOC . TLS has three distict states ( early data , handshake , post handshake ) and the key to use depend on the state irrespective of message type . EDHOC has none of that . A key derivation figure would maybe make more sense if we are to add anything . 
 Suggestion by  to add a reference to an academic paper that has a figure with the key derivation 
 Perhaps sufficient to refer to figure 2 ? 
 I do n't have a strong preference , but fig 3 is used for message_4 . 
 But message_4 will likely not be used in most deployments , so maybe   is enough . 
 I think this can be closed after interim today , unless there are any more comments .
Paragraph (version A):
This section defines Extract, Expand and other key derivation
functions based on these: Expand is used to define EDHOC-KDF and in
turn EDHOC-Exporter, whereas Extract is used to define EDHOC-
KeyUpdate.
Paragraph (version B):
This section defines Extract, Expand and other key derivation
functions based on these: Expand is used to define EDHOC-KDF and in
turn EDHOC-Exporter, whereas Extract is used to define EDHOC-
KeyUpdate.  In EDHOC a specific message always use the same key, but
how the key is derived depends on the method.  A diagram of the EDHOC
key schedule can be found in Figure 2 of Vucinic22.
Draft: draft-ietf-lake-edhoc

Commentary: Based on the first comment in Stephen 's review . 
 Closing this since is merged .
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.
Paragraph (version A):
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.  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):
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.
Draft: draft-ietf-lake-edhoc

Commentary: Looks good to me
Paragraph (version B):
EDHOC does not have a dedicated message field to indicate protocol
version.  Breaking changes to EDHOC can be introduced by specifying
and registering new methods.
Paragraph (version A):
Error code 1 is used for errors that do not have a specific error
code defined.  ERR_INFO MUST be a text string containing a human-
readable diagnostic message written in English.  The diagnostic text
message is mainly intended for software engineers that during
debugging need to interpret it in the context of the EDHOC
specification.  The diagnostic message SHOULD be provided to the
calling application where it SHOULD be logged.
Paragraph (version B):
Error code 1 is used for errors that do not have a specific error
code defined.  ERR_INFO MUST be a text string containing a human-
readable diagnostic message written in English, for example "Method
not supported".  The diagnostic text message is mainly intended for
software engineers that during debugging need to interpret it in the
context of the EDHOC specification.  The diagnostic message SHOULD be
provided to the calling application where it SHOULD be logged.