Re: [core] 🔔 Working Group Last Call (WGLC) of draft-ietf-core-oscore-edhoc-06

[Christian Amsüss <[e-mail]>]

Hello,

I have a few comments and questions on the document. They'r in linear
sequence; I hope to not reiterate too much on points that have been
discussed exhaustively (as I'm not up to date on all threads pertaining
to the document).

None are particularly critical (AIU it's the chairs' call whether
something blocks a WGLC anyway, I think most outcomes can be addressed
post-WGLC), although I'd like to see at least the Section 6 example
addressed.


* Section 2 might profit from an introductory line along the lines of

  | This section (is not normative and?) summarizes what is specified in
  | [I-D.ietf-lake-edhoc], in particular its Appendix A.2, and thus
  | provides a base-line for the enhancements in the subsequent
  | sections.

* Figure 4 (full coAP message):

  * There might also be CoAP options before the EDHOC option, in
    particular Observe.

  * Could you add something about "example" in here? Such a message
    could be sent over any transport, such as CoAP-over-TCP, and then
    some of that figure doesn't apply.

* 3.2 Client processing: This speaks of an "original CoAP message". I
  know from context what is meant, but the term could be more
  descriptive. Maybe "Encrypt the first application CoAP request as an
  original message per Section 8.1"?

  (The term reappears in 3.2.1 Supporting Block-wise).

* 3.2 step 3: "The first CBOR byte string is the EDHOC message_3
  resulting from step 1." could tempt an implementer to encode the
  message_3 into a bstr; I take it that the intention is to send
  CIPHERTEXT_3 in only one layer of byte strings.

  I therefore suggest the wording:

  | [...] composed of two CBOR items in the following order.
  |
  | The first CBOR item is the single item of EDHOC_message_3 (which is
  | CIPHERTEXT_3, a byte string).

* 3.2 step 3: I missed that at some point in the evolution of this
  protocol, prefixing the (non-CBOR) OSCORE message with a CBOR stream.

  This seems unnecessary to me, given that the previosu EDHOC_message_3
  is well delimited, and the OSCORE message can well be the bytes to the
  end (a concept for which has been taken up in RFC9277 for CBOR-labeled
  non-CBOR data), and will typically waste 2-3 bytes (rarely 1 -- for
  that, the full OSCORE message needs to fit in 24 bytes).

  Was there a particular reason for this change?

* 3.2.1 item A is quite a mouth-ful to say that "On Inner Block-wise,
  3.2 only applies to the first block", but I see that given how the
  rest is phrased, it is unavoidable.

  Maybe using the term "first application CoAP request" suggested above
  opens an avenue for making this easier to comprehend.
 
* "If the decrypted request includes an EDHOC option but it does not
  include an OSCORE option, the server MUST stop processing the request
  and MUST reply with a 4.00 (Bad Request) error response."

  My understanding of this sentence is that EDHOC's criticality applies
  after decryption again, and a server must not silently ignore an inner
  EDHOC option without a matching OSCORE option.

  While this is in the right scope for a message it processes as an
  end-to-end message, it is out of scope if we're in a oscore-proxies
  situation (which of course we don't have normatively yet, but I don't
  want this to bite us later -- it could bite if, for example, the inner
  OSCORE connection with the origin server used some OSCORE-version-2
  with a dedicated option that our proxy doesn't need to know).

  I suggest the following wording instead:

  | When the decrypted request is checked for any critical options (as
  | it is during regular CoAP processing), the presence of an EDHOC
  | option MUST be regarded as an unprocessed critical option, unless it
  | is processed by some further mechanism.

  (The current phrasing implies that an inner OSCORE option could be
  processed, which is currently still forbidden; this wording avoids
  that while leaving the door open).

* "The EDHOC option is registered with CoAP option number 21.": This
  line could take a note that the RFC editor should remove this line (as
  at time of publication, this will be a registered fact and not an
  assumption).

* 4.1. Additional Processing of EDHOC Messages: So far, this document
  offers an additional mechanism; now suddenly we get universal
  normative requirements. When do these apply? My assumption is that

  | When using EDHOC to establish an OSCORE context, client and server
  | MUST perform additional steps during EDHOC, extending Section 5 of
  | EDHOC:

  (They feel much more like a "needs to" to me, because they all stem
  from requirements in the cited documents, but this sounds like a
  "MUST" that someone insisted on at some point, which I won't fight).

* 4.1.1: This reads needlessly imperative to me -- what does the looping
  process give that a simple

  | The initiator MUST choose a C_I that is neither used in any current
  | EDHOC exchange as this party's identifier, nor the Recipient ID in
  | a current OSCORE context whose ID Context is zero-length. The chosen
  | C_I SHOULD not be the Recipient ID of any current OSCORE context.

  does not give?

  Same goes for section 4.1.2, where the "neither" group gains the C_I
  as an extra clause.

  (The concept of atomicity is not really needed when phrasing it as a
  closed expression rather than an imperative program).

  By the way, there is a subtle error that the above text would fix
  compared to the current text: "If ID* is already used as EDHOC
  Connection Identifier C_I," is only looking at our C_I, but it'd need
  to also look at our C_R for the host can concurrently be in an EDHOC
  exchange where roles are reversed.

* Section 6: I would not expect to have much need of that content, but
  trust that thought went into potential use cases.

  A property that I'd be missing if I wanted to plan a complete EDHOC
  exchange ahead is whether or not the forward or the reverse message
  flow is supported.

  (If I used things that way I'd also want to know, for the cred-t=cwt
  case, which AS's tokens the server would accept, but that's probably
  for the ACE EDHOC profile).

  EDHOC treats application profiles like something that is defined by an
  application (be it as in some-piece-of-software or as in
  some-SDO-protocol), where the set of acceptable methods etc. follows
  from what that application says. Wouldn't it make more sense to guide
  those who define application protocols to how to make the
  application-protocol-as-a-whole discoverable (maybe by declaring
  rt="core.edhoc my-sdo.edhocprofile", or using a dedicated attribute)
  rather than detailing out every single property that profile has?

  I wouldn't expect a device to just go around willy-nilly attempting to
  use any profile where the shoe fits. I'd expect it to know what it
  wants to do (which profile it wants to use), and then search precisely
  for a resource that'll do that profile (and expect the peer to heed
  what's specified in there).

* Figure 6 (The Web Link) gives an example with multiple EDHOC
  resources, without giving any plausible reason for why different
  profiles would be in place. (Note that a single EDHOC resource should
  very well be capable of serving even two different application
  profiles).

  This kind of example has a tendency to be copied over into people's
  setups without much thought, so the thought needs to go in now.

  I suggest taking one of two routes:

  * Explain why there would be two distinct EDHOC resources, or
  * preferred: just describe the /.well-known/edhoc resource

* Figure 6 The Web Link: None of the values in here need quotation marks
  around them.

* Appendix A: Sorry, didn't check this one.

  Frankly, I think this is a bit excessive, and would be more suitable
  for an LWIG document, or the detailed documentation of an EDHOC
  library.

* General: I'm not sure whether it would make sense to define a general
  application profile for "Let's talk OSCORE over CoAP", that allows
  everything that works for EDHOC-OSCORE, and is what /.well-known/edhoc
  would default to.

  Users don't need to do an application profiles when using DTLS
  "web-PKI-style", so why should they here? Or is this a distinction
  mark, because we *don't* expect "web-PKI-style" to be the implied
  default in EDHOC?

BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom