Draft: draft-ietf-lake-edhoc

Commentary: Comment by   
 I think the forward secrecy could use some more text . Right know we are using the definition according to the IETF security dictionary , but as the security dictionary states , a lot of different definitions is used . The draft that the KeyUpdate gives much better security than using a single key , but that the KeyUpdate method gives a lower security level than frequently running ephemeral
Paragraph (version A):
A key material exporter and a key update function enabling
frequent forward secrecy.
Paragraph (version B):
A key material exporter and a key update function enabling forward
secrecy.
Paragraph (version A):
The EDHOC-KeyUpdate takes a nonce as input to guarantee that there
are no short cycles.  The Initiator and the Responder need to agree
on the nonce, which can e.g., be a counter or a random number.
Paragraph (version B):
The EDHOC-KeyUpdate takes a nonce as input to guarantee that there
are no short cycles.  The Initiator and the Responder need to agree
on the nonce, which can e.g., be a counter or a random number.  While
the KeyUpdate method provides forward secrecy it does not give as
strong security properties as re-running EDHOC, see security.
Paragraph (version A):
As required by RFC7258, IETF protocols need to mitigate pervasive
monitoring when possible.  One way to mitigate pervasive monitoring
is to use a key exchange that provides forward secrecy.  EDHOC
therefore only supports methods with forward secrecy.  To limit the
effect of breaches, it is important to limit the use of symmetrical
group keys for bootstrapping.  EDHOC therefore strives to make the
additional cost of using raw public keys and self-signed certificates
as small as possible.  Raw public keys and self-signed certificates
are not a replacement for a public key infrastructure but SHOULD be
used instead of symmetrical group keys for bootstrapping.
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 KeyUpdate function for
lightweight application protocol rekeying with forward secrecy.  As
discussed in RFC4949 the term "forward secrecy" is a muddled area.
EDHOC provides 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.
Paragraph (version B):
While the KeyUpdate method can be used to meet cryptographic limits
and provide partial protection against key leakage, it provides
significantly weaker security properties than re-running EDHOC with
ephemeral Diffie-Hellman.  Even with frequent use of KeyUpdate,
compromise of one session key compromises all future session keys,
and an attacker therefore only needs to perform static key
exfiltration RFC7624.  Frequently re-running EDHOC with ephemeral
Diffie-Hellman forces attackers to perform dynamic key exfiltration
instead of static key exfiltration RFC7624.  In the dynamic case, the
attacker must have continuous interactions with the collaborator,
which is more complicated and has a higher risk profile than the
static case.
Paragraph (version B):
To limit the effect of breaches, it is important to limit the use of
symmetrical group keys for bootstrapping.  EDHOC therefore strives to
make the additional cost of using raw public keys and self-signed
certificates as small as possible.  Raw public keys and self-signed
certificates are not a replacement for a public key infrastructure
but SHOULD be used instead of symmetrical group keys for
bootstrapping.
Paragraph (version A):
The data rates in many IoT deployments are very limited.  Given that
the application keys are protected as well as the long-term
authentication keys they can often be used for years or even decades
before the cryptographic limits are reached.  If the application keys
established through EDHOC need to be renewed, the communicating
parties can derive application keys with other labels or run EDHOC
again.