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

[Göran Selander <[e-mail]>]

Hi Roman,

Thanks for your review. It is tracked as github issue #422<https://github.com/lake-wg/edhoc/issues/422> and updates are in PR #426<https://github.com/lake-wg/edhoc/pull/426>.

Please find responses to your comments inline below.


From: Roman Danyliw via Datatracker <[e-mail]>
Date: Wednesday, 23 August 2023 at 02:50
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Roman Danyliw's Discuss on draft-ietf-lake-edhoc-20: (with DISCUSS and COMMENT)
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?


[] As you already noticed, x5bag is defined by RFC 9360. When using x5bag in COSE without EDHOC the endpoint already have to find the end entity certificate. The key in the end entity cert is need to process the COSE message. EDHOC does not add any requirements beyond what COSE already requires. My understanding is that the Certificate Message in TLS can also be a bag. We agree that processing a bag adds complexity that are not well suited for constrained IoT devices. In the worst case I assume you might end-up with several potential end entity certificates and you have to try several to find the correct one. As EDHOC does not add any additional requirements on top of COSE I don't think it makes sense to detail bag processing in the EDHOC specification. Given the problems for constrained IoT devices and bag, we added a sentence describing the problems with bag and a recommendation of using chain. We also changed the reference from RFC 5280 to RFC 9360 which defined x5bag and x5chain.


----------------------------------------------------------------------
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?
[] Fragmentation can occur on different layers and the effect of fragmentation depends on technology. For radio links, like LoRAWAN with duty cycle in some regions the penalty of splitting a message is large. For cellular IoT, like NB-IoT there are less visible threshold effects, more a gradual decrease of characteristics with increasing message size. But there are lots of other things to consider. For example, the probability and effects of bit errors, which in turn depends on message size since a larger message has a higher probability for error. Considering these types of effects and others it may be difficult to specify a minimum PDU with the properties you request. In the requirements phase (draft-ietf-lake-reqs-04) we looked at deployments of NB-IoT, 6TiSCH and LoRaWAN. Even for this small set of technologies there are many aspects to consider. What we did find in this work was that with messages of size of 45 bytes and less, common deployments of these radio technologies are expected to deliver good performance, and that this size is achievable with CBOR, COSE and CoAP. I don’t know if this answers your question.


** 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”?

[] This is referring to the specific encoding of authentication credential specified in the application profile, mentioned in the previous paragraph. The paragraphs are now merged with further explanatory text.



** 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?

[] It is not a requirement for the security protocol, but since duplicate messages lead to session abortion it is a highly recommended property. See response to Martin Duke's review
https://mailarchive.ietf.org/arch/msg/lake/wuoYFmItMlbtNMYzHDH1ZAOHlno/
and proposed update of section 3.4 in
https://github.com/lake-wg/edhoc/pull/429

** 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.
[] An explaination is added and a citation of NIST.


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

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

[] Removed the normative SHOULD and reformulated to: “Implementations and users should take these threat models into account and consider actions to reduce the risk of tracking by other endpoints.”

** 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?

[] The intent is to recommend the implementation to actually make use of available mitigations against DoS as examplified in the text following the quoted sentence.  A clarification is attempted.

** 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?


[] John provided a lot of comments to NIST SP 800-108 which led to NIST updating that specification.
https://csrc.nist.gov/files/pubs/sp/800/108/r1/final/docs/sp800-108r1-draft-comments-resolutions.pdf
SP 800-108 now aligns with [HKDFpaper] in that a secure KDF needs to handle non-secret information as well. We added references to both 800-56A and 800-108 to capture this. We also moved the paragraph to "cryptographic considerations" as this is not implementation considerations.
[HKDFpaper] https://eprint.iacr.org/2010/264.pdf

** 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.

[] The sentence is removed. I don't think taking a position that implementations should do this is appropriate. And if taking a stance needs to be done, the sentence does not fill the purpose.

** 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?

[] There is not link between them. The two sentences are moved to two other paragraphs were they fit better.