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

From: Russ Housley <[email-masked]>
Date: Tue, 26 Feb 2019 17:59:21 -0500

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.

---

From: John Mattsson <[email-masked]>
Date: Wed, 27 Feb 2019 10:34:57 +0000

Thanks for the review Russ!

Some comments inline

Cheers,
John

-----Original Message-----
From: Cfrg <[email-masked]> on behalf of Russ Housley <[email-masked]>
Date: Tuesday, 26 February 2019 at 23:59
To: IRTF CFRG <[email-masked]>
Subject: [Cfrg] Crypto-panel review of draft-selander-ace-cose-ecdhe-12

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

The document is also freely available on one of the authors webpages, but I do not know if it is the exact same version.

https://alessandrobruni.name/papers/18-edhoc.pdf

>consequences for using a group PSK to be discussed in Section 9.

The protocol clearly do not provide mutual authentication when more than one party knows the private keys or PSK. I agree that this could be written out in Section 4 and 5 and that the consequences of disclosure should be discussed in Section 9. We will add that in the next version.

>I have the same comments as above regarding C_U.

Good points. 

- The stated flexibility has been tuned done in version 12, and it has been made clearer that the main focus is transport over CoAP. We do not want to forbid any other transports but we do not want to spend too much time specifying it either.

- I see now that the description of a null connection identifier is missing for one side. E.g. for message two it is stated that

"To reduce message overhead, party V can set the message field C_U in message_2 to null (still storing the actual value of C_U) if there is an external correlation mechanism (e.g. the Token in CoAP) that enables Party U to correlate message_1 and message_2."

Any guidance for Party U is missing, and vice verse for message_3. This needs to be added if the optimization is kept.

- It can be discussed if the added complexity of having two options are worth the savings. Assuming CoAP is used for transport and 1 byte connection identifiers are used (which allows a node to have 256 connections), the added complexity only saves a single byte. On the other hand, there are not many spare bytes if you want to fit EDHOC into three single 51 byte LoRaWAN frames.

>   set to aad_2 and aad_3, respectively.

Good suggestions, we'll change according to your suggestions.

>the sections define the aad_2 and aad_3 structures.

That was added to Section 3.3. in versrion 12: "where aad_2 and aad_3 are hashes of previous messages and data, defined in Sections 4.3.1 and 4.4.1." Is there any other place that would benefit from a pointers?

>I suggest: "where ID_CRED_U and ID_CRED_V are encoded in a COSE map."

Good suggestions, we'll change according to your suggestions.

>Section 9.2: s/provide aliveness/provide liveness/

Thanks for the nits, we will fix them.

>document is adopted into a working group.

Yes, and any such discussion is welcome. Curve25519 and EdDSA have clear benefits when it comes to processing, but are clearly less supported by hardware and libraries. EdDSA also mandates SHA-512 while many IoT devices support only SHA-256. In EDHOC the choice between ECDH algorithms does not affect the message sizes, but if EDHOC is used with COSE x5chain or x5bag it would make a difference. The choice should likely be coordinated with Group OSCORE 

https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm

While EDHOC cannot be used to key the group communication in Group OSCORE, devices would likely implement both Group OSCORE and EDHOC, and EDHOC could be used to key the OSCORE connection between a single endpoint and the group manager in Group OSCORE.

_______________________________________________
Cfrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/cfrg

---

From: Russ Housley <[email-masked]>
Date: Wed, 27 Feb 2019 10:02:44 -0500

> That was added to Section 3.3. in versrion 12: "where aad_2 and aad_3 are hashes of previous messages and data, defined in Sections 4.3.1 and 4.4.1." Is there any other place that would benefit fro…

This is a minor concern, but to me, the pointers would have been more useful in the bullets earlier in Section 3.3.

Russ