[Cfrg] Crypto-panel review of draft-selander-ace-cose-ecdhe-12

[Russ Housley <[e-mail]>]

Document: draft-selander-ace-cose-ecdhe-12
Reviewer: Russ Housley
Review Date: 2019-02-26


The CFRG Chairs asked the Crypto Panel to review this document.
I am providing one review.  There may be others.


Summary:

The protocol seems to be as advertised, but the security considerations
need to be expanded as described below.  In addition, I raise a concern
about the connection identifiers, but I do not think that is hard to
address.

I did not look at the formal analysis in [1].  It is behind a paywall.

I did not review the appendices.

[1] https://link.springer.com/content/pdf/10.1007%2F978-3-030-04762-7_2.pdf



Major Concerns:

I do not think the protocol provides mutual authentication when more
than one party knows the signature private key.  This applies to both
the raw public keys (RPK) and public key certificates.  I expected to
see the protection requirements for the private key in Section 4.  I
also expected the consequences for disclosure of the private key be
discussed in Section 9.

I do not think the protocol provides mutual authentication when
symmetric keys are used for authentication unless the PSK is only known
to the two parties involved in the protocol.  I expected to see the need
for a pairwise PSK to be highlighted in Section 5.  I also expected the
consequences for using a group PSK to be discussed in Section 9.

Section 4.3.1 says:

   C_U : bstr / nil,

And then, Sections 4.3.3 says:

   Retrieve the protocol state using the connection identifier C_U

It seems odd to have the complexity of two options here.  I think it
would be better to always send C_U or never send it.  Section 4.3.3
needs to say how to process Message 2 if C_U is omitted.  Given the
flexibility claimed in the Introduction, I am assuming that a
connection-oriented transport is not required.  If this protocol is
on top of a connectionless transport, I think C_U is required.

Section 4.4.1 says:

   C_V : bstr / nil,
   
And then, Sections 4.4.3 says:

   Retrieve the protocol state using the connection identifier C_V

I have the same comments as above regarding C_U.


Minor Concerns:

Section 2 includes Figure 1.  Next, it explains the elements used in the
figure, which includes AEAD.  Next, it lists the things that need to be
added to get a "full-fledged" protocol, which again includes AEAD.  AEAD
should be removed from the second list.

Section 3.2 says "... but only a subset of the parameters is included in
the EDHOC messages."  Please list the subset or provide a pointer to the
place where that can be found.

Section 3.3 says:

   For message_i the key, called K_i, SHALL be derived using other =
   aad_i, where i = 2 or 3.

Since there are only two cases, it would be clearer to say:

   For message_2 and message_3, the keys SHALL be derived using other
   set to aad_2 and aad_3, respectively.

In addition, it would help the reader to provide a forward pointer to
the sections define the aad_2 and aad_3 structures.

The paragraph that follows talks about the IV_i.  Again, I think this
simpler language would help the reader.

Section 4.1, please avoid "for x = U or V" the first time it is used.
I suggest: "where ID_CRED_U and ID_CRED_V are encoded in a COSE map."

Section 4.3.1 says:

   C_U : bstr / nil,

And then, Sections 4.3.3 says:

   Retrieve the protocol state using the connection identifier C_U

It seems odd to have the complexity of two options here.  I think it
would be better to always send C_U or never send it.  Section 4.3.3
needs to say how to process message_2 if C_U is omitted.  Given the
flexibility claimed in the Introduction, I am assuming that a
connection-oriented protocol is not required.


Nits:

The point that EDHOC makes use of CBOR, CoAP, and COSE is repeated too
many times.

Both "perfect forward secrecy" and "perfect-forward secrecy" are used.
Please pick one and use it everywhere.  I prefer the first spelling.

Section 1: it seems better to end the first sentence as, "... or where
the protection needs to work over a variety of underlying protocols."

Section 1.1: s/systems often deals with/systems often deal with/

Section 1.2: s/(CDDL) to express CBOR/(CDDL) is used to express CBOR/

Section 7.1: s/It is recommended is to/It is recommended to/

Section 9.2: s/provide aliveness/provide liveness/


Prediction:

The mandatory-to-implement algorithm will probably get debated if this
document is adopted into a working group.