Subject: [Lake] spt review of echoc-12

From: Sean Turner <[email-masked]>
Date: Wed, 15 Dec 2021 01:35:00 -0500

Like others I agreed to review the edhoc I-D at the last meeting. I did not have a chance to make sure that I am not repeating comments from others. To save the WG some time, I tried to categorize these along the lines of questions/nits where discuss might need some f2f time and nits, I believe, can be dealt with by the authors as they see fit.

Disclaimers: 0) I am not a cryptographer or security researcher. 1) It is entirely possible I am entirely missing the plot/point. 

Apologies: I ran out of time to submit these as Issues/PRs. I can do so after the interim, including those that got rejected at the 12/15 interim for posterity sake. 

s1.2 (nit): If s1.2 is supposed to be an applicability statement in the context of RFC 2026, can we call it that. i.e., r/Use of EDHOC/Applicability Statement. 

revised: And then, I see section 3.9. Maybe instead of renaming s1.2, a forward pointer to s3.9 is all that is needed to say that an applicability statement is required?

s2, 2nd para (nit): refer to both because it’s (D)TLS and not just TLS?  I.e.,
s/(D)TLS 1.3 [RFC8446]/(D)TLS 1.3 [RFC8446] [I-D.ietf-tls-dtls13]

s2, 2nd para (nit): I think you can safely drop the 2nd reference to IKEv2
s/like IKEv2 [RFC7296],/like IKEv2,

s3.2/s3.5.2 (question): Smarter people than I have devised plans to allow mixing of different METHODs. How does this impact the key usage extension present in certificates? In other words, are METHODS 1 and 2 suggesting that a DS and DH key be used together and does that violate any kind of restrictions on the key usage settings for certificates?

s3.4 (nit): Is transport of error messages, as noted by s6 (2nd para), needed in the list.

s3.5 para after the bullets (nit): I think you are trying to say the credentials have to be the same type, i.e., you can’t have PGP one one side and x.509 on the other. I am not sure that the following is the best wording:

s/Identical authentication credentials need to be established in both endpoints to be able to verify integrity./The same type of authentication credentials are needed baby the endpoints to be able to verify integrity.

s3.5.1, 1st para (nit): At first I thought for sure this had to be a MUST, but it says or application so I am not sure:

The EDHOC implementation or the application must enforce information about the intended endpoint …

s3.5.1 (nit): expand on first use NAI & EUI

s3.5.1, 1st bullet (nit): Often we refer to this a Proof-of-Possession so maybe you could say that:

s/EDHOC provides
      proof that the other party possesses the private authentication
      key corresponding to the public authentication key in its
      certificate./EDHOC provides
      proof that the other party possesses the private authentication
      key corresponding to the public authentication key in its
      certificate, which is also known as proof-of-possesion.

s3.5.1, 1st bullet (question): This seems like the “mixing” discussed in s3.2, relies on the identity provide in the certificate?

    The certification path provides proof that the
    subject of the certificate owns the public key in the certificate.

s3.5.2 (question): related to comment on s3.2.

s3.5.3, 2nd para (nit): Could point to RFC 3279/5480 for some key usages for ECDSA and RFC 8410 for x25519/x448.

In
   X.509 and C509 certificates, signature keys typically have key usage
   "digitalSignature" and Diffie-Hellman public keys typically have key
   usage "keyAgreement" [RFC3279][RFC8410].

s3.6 (nit): refer to both?:
s/TLS 1.3 [RFC8446]/
(D)TLS 1.3 [RFC8446] [I-D.ietf-tls-dtls13]

s3.5.3 (question): EDHOC seems to assume you only provide the reference for the initiator's/responder’s. Was there any thought it to providing references for the rest of the certification path up to but not including the Root CA’s certificate? I mean technically they can also be in there certificate provided so not necessarily needed.

s3.6, CNSA ref (nit): I made a similar comment against the ZRTP spec when they said their alg suites were compliant with Suite B … probably best to say Suite 24 and 25 use algorithms in CNSA and leave the word “compatible” for “them” to say.

s3.8 (comment): Wow .. so you can send in the CSR in EAD, if it works then you can use the cert in the later messages (e.g., kind of like EAP)? Sure hope there’s no kind of CSR-related error. And, you know that the CA gets to decide the name right. Sorry just trying to digest it all.

s4.3 (nit): s/kan/can

s4.4/s5.1 (question): Do you need to provide advice on when to delete the old PRK_4x3m? I.e., does the peer that sent this need to wait for some kind of confirmation before deleting it?

s5.1 (question): Is a state diagram needed? One thing people clamored for from TLS was a state machine. Maybe a diagram isn’t needed because there are so few states?

s5.1 (comment, no action required): Cute. Deduplication is how to deal with message reply ;)

s5.2.1, s.5.3.1, s5.4.1, s5.5.1 (nit): is the “,” before the closing bracket right? e.g.,

OLD:

    ? EAD_1 : ead,
}

NEW:

    ? EAD_1 : ead
}

s5.2.2 (question): If this this initiator processing section, how does the initiator know to truncate?

  …, truncated after the cipher suite selected for this
  session.

s5.2.3, s5.3.3, s5.4.3, s5.5.3, last sentence (question - probably being pedantic): If there is an error but an error message is not sent, is the session discontinued? How does the peer know it was discontinued if an error is not sent?

s5.2.3, s5.3.3, s5.4.3, s5.5.3 (nit, which I am sure the RFC editor fix better than I could, but I couldn’t help myself): Instead of the e.g., in middle of the MAY sentence maybe:

OLD:

   Sending error
   messages is essential for debugging but MAY e.g., be skipped if a
   session cannot be found or due to denial-of-service reasons, see
   Section 8.6.

NEW:

   Sending error
   messages is essential for debugging but MAY be skipped if, for
   example, a
   session cannot be found or due to denial-of-service reasons, see
   Section 8.6.

s6.1 (nit): To stop loops, should any peer that receives an ERR_CODE=0 discontinue the session? I.e., is that worth stating in the I-D?

s6.2 (nit): It’s really more “Freeform” than unspecified right? I mean the string is required so it’s definitely not unspecified per se.

s6.3.2, 2nd to last para (nit): s/shall/SHALL

s6.3.2/s5.2.1 (nit): Might be worth noting earlier that SUITES_R is not important. Also, s5.2.1, mentioned SUITES_I, but s5.2.2 does not mention SUITES_R.

s7, last para (nit): s/To enable as much interoperability as we can
   reasonably achieve,/To enable as much interoperability as possible,

s8 (question): Isn’t some kind of consideration needed to address the use of PSKs shared by more than two? See RFC 8773 for some considerations wrt to group key sharing and that sharing impact on authentication.

s8.3 (nit): You can informatively refer to RFC 6194 to slam the door on SHA-1.

s9 and onwaard (apologies): I ran out of steam.

s? (question): Is a peer supposed to check status information for its peer’s certificate/key? 

I-D Nit complaints (not all of them because the DOWNREFs (mostly) looked intentional):

== Missing Reference: 'RFC9052' is mentioned on line 2411, but not defined

Cheers,
spt

---

From: <[email-masked]>
Date: Thu, 16 Dec 2021 08:38:25 +0000

Hello LAKE,

Sorry for this very late remark. But it seems that "EdDSA" is not the proper wording to use in the draft (at least in Section 9.2). I quote the original paper by Bernstein, Duif, Lange, Schwabe and Yang [1]: 
- " This section specifies the signature system used in this paper, and a generalized signature system EdDSA that can be used with other choices of elliptic curves."
- " Our recommended curve for EdDSA is a twisted Edwards curve birationally equivalent to the curve Curve25519 [...] We use the name Ed25519 for EdDSA with this particular choice of curve."
Therefore "Ed25519" should be used in place of "EdDSA" (at least in Section 9.2). 

What do you reckon?

Best regards

[1] High-speed high-security signature, Bernstein, Duif, Lange, Schwabe and Yang, 2011. https://ed25519.cr.yp.to/ed25519-20110926.pdf

Loïc Ferreira
Orange Labs – Applied Cryptography Group
+33 (0)2 31 15 91 24
[email-masked]

Orange Restricted

-----Message d'origine-----
De : Lake <[email-masked]> De la part de Sean Turner
Envoyé : mercredi 15 décembre 2021 07:35
À : LAKE List <[email-masked]>
Objet : [Lake] spt review of echoc-12

s2, 2nd para (nit): refer to both because it’s (D)TLS and not just TLS?  I.e., s/(D)TLS 1.3 [RFC8446]/(D)TLS 1.3 [RFC8446] [I-D.ietf-tls-dtls13]

s2, 2nd para (nit): I think you can safely drop the 2nd reference to IKEv2 s/like IKEv2 [RFC7296],/like IKEv2,

s/EDHOC provides

In

s4.3 (nit): s/kan/can

OLD:

    ? EAD_1 : ead,
}

NEW:

    ? EAD_1 : ead
}

OLD:

   Sending error

NEW:

   Sending error

Cheers,
spt
--
Lake mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lake

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Göran Selander <[email-masked]>
Date: Thu, 16 Dec 2021 09:50:38 +0000

Hi Loïc,

Thanks for the comment. It is not too late and makes sense to me. I opened an issue:
https://github.com/lake-wg/edhoc/issues/218

Göran

From: Lake <[email-masked]> on behalf of [email-masked] <[email-masked]>
Date: Thursday, 16 December 2021 at 09:40
To: LAKE List <[email-masked]>
Subject: Re: [Lake] spt review of echoc-12
Hello LAKE,

What do you reckon?

Best regards

[1] High-speed high-security signature, Bernstein, Duif, Lange, Schwabe and Yang, 2011. https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-1b801206d8bfce4f&q=1&e=371d7c78-5c57-49c2-8785-e20bf038bf86&u=https%3A%2F%2Fed25519.cr.yp.to%2Fed25519-20110926.pdf

Loïc Ferreira

Orange Restricted

-----Message d'origine-----
De : Lake <[email-masked]> De la part de Sean Turner
Envoyé : mercredi 15 décembre 2021 07:35
À : LAKE List <[email-masked]>
Objet : [Lake] spt review of echoc-12

s/EDHOC provides

In

s4.3 (nit): s/kan/can

OLD:

    ? EAD_1 : ead,
}

NEW:

    ? EAD_1 : ead
}

OLD:

   Sending error

NEW:

   Sending error

Cheers,
spt
--
Lake mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-49a34bb25e2c1426&q=1&e=371d7c78-5c57-49c2-8785-e20bf038bf86&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake

--
Lake mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-49a34bb25e2c1426&q=1&e=371d7c78-5c57-49c2-8785-e20bf038bf86&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake