[Lake] Roman Danyliw's Discuss on draft-ietf-lake-edhoc-20: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-lake-edhoc-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 3.5.2
When the identified credential is a
   chain or a bag, the authentication credential CRED_x is just the end
   entity X.509 or C509 certificate / CWT.

Per Section 2 of RFC9360, the x5bag claim is:

"This header parameter contains a bag of X.509 certificates. The set of
certificates in this header parameter is unordered and may contain self-signed
certificates. Note that there could be duplicating certificates. The
certificate bag can contain certificates which are completely extraneous to the
message."

How does one pick-out the “end entity” if the list contains self-signed or
extraneous certificates?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Radia Perlman for the SECDIR review.

** Section 3.4.
   EDHOC is not bound to a particular transport layer and can
   even be used in environments without IP.

Is there a minimum transport PDU for EDHOC? That is, if too small, EDHOC would
fragment and eliminate all of the design benefits of limited round trips?

** Section 3.5.2
   It is RECOMMENDED that the COSE 'kid' parameter, when used to
   identify the authentication credential, refers to a specific
   encoding.

In what way does the “kid” claim convey a “specific encoding”?

** Section 7.  This section seems to be discussing how EDHOC implementations
handle message duplication.  However, Section 3.4 says that “… the transport is
responsible … to handle … message duplication”.  Is it a transport requirement
or not to handle duplication?

** Section 9.4
   Symmetric algorithms used in EDHOC such as SHA-256 and AES-CCM-
   16-64-128 are practically secure against even large quantum
   computers.

Could “AES-CCM-16-16-128” being “practically secure” be better explained or
cited.

** Section 9.6.
   Implementations and users SHOULD consider
   these threat models.

What does a normative “SHOULD” to “consider” a threat model mean?

** Section 9.7
EDHOC itself does not provide countermeasures against Denial-of-
   Service attacks.
...
To
   mitigate such attacks, an implementation SHOULD rely on lower layer
   mechanisms.

What is the intent of this normative guidance?  If EDHOC doesn’t have DoS
protection, what is the alternative relying on a lower level (stated as a
SHOULD here)?  Is it an application mechanism?

** Section 9.8
   NIST
   generally forbids deriving secret and non-secret randomness from the
   same KDF instance,

Can the basis of this prohibition be cited?

** Section 9.8.

   Implementations might consider deriving secret and non-secret
   randomness from different PRNG/PRF/KDF instances to limit the damage
   if the PRNG/PRF/KDF turns out to be fundamentally broken.
   ...

I’m confused on the position this entire paragraph is taking.  It’s framed as
“might consider.” It then describes that there is conflicting advice from NIST
and [HKDFpaper].  Either removing this text or state an explicit position.

** Section 9.8
   Verification of validity may require the use of a Real-Time Clock
   (RTC).  The private authentication keys MUST be kept secret, only the
   Responder SHALL have access to the Responder's private authentication
   key and only the Initiator SHALL have access to the Initiator's
   private authentication key.

Can the link between the two sentences in this paragraph be clarified?  How is
the need for a clock connected to keeping the authentication keys secret?