Draft: draft-ietf-lake-edhoc

Commentary: Issue 
 Minor comment , but reading through all the security claims , they multiple times refer to the term ( for instance in ) , which is not per say completely defined . I am not even sure there is any ambiguity , but is it still worth adding somewhere that this relates to ? 
 Yes , I assume session key most often refer to PRK_out . Could maybe refer to the exported application keys in some sentence . Let 's go through all instances and make it clear what it refers to .
Paragraph (version A):
The parties exchanging messages are called Initiator (I) and
Responder (R).  They exchange ephemeral public keys, compute a shared
secret key PRK_out, and derive symmetric application keys used to
protect application data.
Paragraph (version B):
The parties exchanging messages are called Initiator (I) and
Responder (R).  They exchange ephemeral public keys, compute a shared
secret session key PRK_out, and derive symmetric application keys
used to protect application data.
Paragraph (version A):
EDHOC uses Extract-and-Expand RFC5869 with the EDHOC hash algorithm
in the selected cipher suite to derive keys used in message
processing.  This section defines Extract (extract) and Expand
(expand), and how to use them to derive PRK_out (prkout) which is the
shared secret key resulting from a successful EDHOC exchange.
Paragraph (version B):
EDHOC uses Extract-and-Expand RFC5869 with the EDHOC hash algorithm
in the selected cipher suite to derive keys used in message
processing.  This section defines Extract (extract) and Expand
(expand), and how to use them to derive PRK_out (prkout) which is the
shared secret session key resulting from a successful EDHOC exchange.
Paragraph (version A):
The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is
the output of a successful EDHOC exchange.  Keys for applications are
derived from PRK_out, see exporter.  For the purpose of using EDHOC-
Exporter, an application only needs to store PRK_out or PRK_exporter.
(Note that the word "store" used here does not imply that the
application has access to the plaintext PRK_out since that may be
reserved for code within a TEE, see impl-cons).
Paragraph (version B):
The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is
the output session key of a successful EDHOC exchange.  Keys for
applications are derived from PRK_out, see exporter.  For the purpose
of using EDHOC-Exporter, an application only needs to store PRK_out
or PRK_exporter.  (Note that the word "store" used here does not
imply that the application has access to the plaintext PRK_out since
that may be reserved for code within a TEE, see impl-cons).
Paragraph (version A):
As required by RFC7258, IETF protocols need to mitigate pervasive
monitoring when possible.  EDHOC therefore only supports methods with
ephemeral Diffie-Hellman and provides a key update function (see
keyupdate) for lightweight application protocol rekeying.  Either of
these provide forward secrecy, in the sense that compromise of the
private authentication keys does not compromise past session keys,
and compromise of a session key does not compromise past session
keys.  Frequently re-running EDHOC with ephemeral Diffie-Hellman
forces attackers to perform dynamic key exfiltration where the
attacker must have continuous interactions with the collaborator,
which is a significant complication.
Paragraph (version B):
As required by RFC7258, IETF protocols need to mitigate pervasive
monitoring when possible.  EDHOC therefore only supports methods with
ephemeral Diffie-Hellman and provides a key update function (see
keyupdate) for lightweight application protocol rekeying.  Either of
these provide forward secrecy, in the sense that compromise of the
private authentication keys does not compromise past session keys
(PRK_out), and compromise of a session key does not compromise past
session keys.  Frequently re-running EDHOC with ephemeral Diffie-
Hellman forces attackers to perform dynamic key exfiltration where
the attacker must have continuous interactions with the collaborator,
which is a significant complication.
Paragraph (version A):
Compromise of the long-term keys (private signature or static DH
keys) does not compromise the security of completed EDHOC exchanges.
Compromising the private authentication keys of one party lets an
active attacker impersonate that compromised party in EDHOC exchanges
with other parties but does not let the attacker impersonate other
parties in EDHOC exchanges with the compromised party.  Compromise of
the long-term keys does not enable a passive attacker to compromise
future session keys.  Compromise of the HDKF input parameters (ECDH
shared secret) leads to compromise of all session keys derived from
that compromised shared secret.  Compromise of one session key does
not compromise other session keys.  Compromise of PRK_out leads to
compromise of all keying material derived with the EDHOC-Exporter.
Paragraph (version B):
Compromise of the long-term keys (private signature or static DH
keys) does not compromise the security of completed EDHOC exchanges.
Compromising the private authentication keys of one party lets an
active attacker impersonate that compromised party in EDHOC exchanges
with other parties but does not let the attacker impersonate other
parties in EDHOC exchanges with the compromised party.  Compromise of
the long-term keys does not enable a passive attacker to compromise
future session keys (PRK_out).  Compromise of the HDKF input
parameters (ECDH shared secret) leads to compromise of all session
keys derived from that compromised shared secret.  Compromise of one
session key does not compromise other session keys.  Compromise of
PRK_out leads to compromise of all keying material derived with the
EDHOC-Exporter.