Re: [secdir] [Lake] Secdir review of draft-ietf-lake-edhoc-18

[John Mattsson <[e-mail]>]

Thanks Marco. That makes sense to me. 

Cheers, 
John 

From: Marco Tiloca <[e-mail]>
Date: Thursday, 26 January 2023 at 10:48
To: John Mattsson <john.mattsson=[e-mail]>, Göran Selander <[e-mail]>, Radia Perlman <[e-mail]>, [e-mail] <[e-mail]>, The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Lake] Secdir review of draft-ietf-lake-edhoc-18 

Hi John, 
On 2023-01-26 00:40, John Mattsson wrote: 

Which changes should we do based on Radia’s comments? 

- Do we need to explain better that EDHOC always do ephemeral-ephemeral key exchange giving forward secrecy with respect to the long-term authentication keys? 
- I don’t think we should change the name of the “Static DH keys”. But we should explain that they are only used for authentication and that an ephemeral-ephemeral key exchange is still performed. 
- Is the term ephemeral DH confusing? Should the body talk about ephemeral-ephemeral instead? - Should Appendix J be thrown out? It is not used by KUDOS anymore. 

==>MT
I think it's better to keep Appendix J.

Also based on the related discussions from the LAKE interim meeting on 2022-10-05:

* EDHOC-KeyUpdate is used in the EDHOC & OSCORE profile of ACE [1], for peers not supporting KUDOS [2].

* Stephen suggested to keep that content altogether (even if as an Appendix), in order to ensure to take into account BCP 107 [3].

Best,
/Marco


[0] https://datatracker.ietf.org/doc/minutes-interim-2022-lake-02-202210051700/ <https://datatracker.ietf.org/doc/minutes-interim-2022-lake-02-202210051700/>

[1] https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile-00#name-use-of-edhoc-keyupdate <https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile-00#name-use-of-edhoc-keyupdate>

[2] https://datatracker.ietf.org/doc/draft-ietf-core-oscore-key-update/ <https://datatracker.ietf.org/doc/draft-ietf-core-oscore-key-update/>

[3] https://datatracker.ietf.org/doc/html/rfc4107 <https://datatracker.ietf.org/doc/html/rfc4107>

<==




Cheers, 
John 

From: Göran Selander <[e-mail]> <mailto:[e-mail]>
Date: Wednesday, 25 January 2023 at 23:21
To: Radia Perlman <[e-mail]> <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>, The IESG <[e-mail]> <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>
Subject: Re: Secdir review of draft-ietf-lake-edhoc-18 

The formatting was messed up in the my response to Radia’s review which made it difficult to distinguish between the review and the response. Here is the same mail repeated but where my inline comments are prepended with [GS]. 




Hi Radia, 

Thanks very much for your secdir review. Please see comments inline. 

Updates are being tracked in PR #395. 
https://github.com/lake-wg/edhoc/pull/395 <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-0214171e5057b187&amp;q=1&amp;e=796763d1-d3a7-40d6-a1f3-e2af5448b2cf&amp;u=https%3A%2F%2Feur05.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fprotect2.fireeye.com%252Fv1%252Furl%253Fk%253D31323334-501d5122-313273af-454445555731-bb10ca2ae3c3bf76%2526q%253D1%2526e%253D427745ef-5c95-47a0-829a-3e732e155bd9%2526u%253Dhttps%25253A%25252F%25252Fgithub.com%25252Flake-wg%25252Fedhoc%25252Fpull%25252F395%26data%3D05%257C01%257Cmarco.tiloca%2540ri.se%257C0573e835d4604c96a0ff08daff2d8689%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C638102868263280565%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26sdata%3DQPfvjZ5MyHzkY53BWuY%252B9XsCfScb2HYJif2aBo69Y4E%253D%26reserved%3D0> 

From: Radia Perlman <[e-mail]> <mailto:&amp;lt;[e-mail]&amp;gt;> 
Date: Tuesday, 24 January 2023 at 03:49 
To: [e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:&amp;lt;[e-mail]&amp;gt;>, The IESG <[e-mail]> <mailto:&amp;lt;[e-mail]&amp;gt;>, [e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:&amp;lt;[e-mail]&amp;gt;> 
Subject: Secdir review of draft-ietf-lake-edhoc-18 

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. 

There are a family of "lightweight" protocols designed for us in "constrained" environments (think IoT) that replace other IETF protocols that would be otherwise be used. The constraints may include lack of CPU power, lack of bandwidth, lack of non-volatile memory, and running over a non-IP network. 

EDHOC (Ephemeral Diffie-Hellman over COSE) specifies a protocol for establishing session keys for use with OSCORE that specifies how to cryptographically protect a session. So you can think of EDHOC as corresponding to IKE while OSCORE corresponds to ESP, or you can think of the pair EDHOC/OSCORE as corresponding to TLS. As you would expect, the protocol is functionally quite similar to both TLS and IKE, and the interesting security discussions would be around the justifications for the differences. 

The name EDHOC is misleading, since EDHOC supports four authentication variants, only one of which is Ephemeral Diffie-Hellman. The other three are where one of both endpoints use a static Diffie-Hellman key. 

[GS] There seems to be a misunderstanding here. All four methods are using ephemeral Diffie-Hellman, although some use additionally static DH for authentication and some use signature for authentication. The message fields G_X in message_1, and G_Y in message_2 are ephemeral public keys and the shared secret G_XY is the Input Key Material for the pseudorandom key PRK_2e for all methods. Is there some text that is unclear on this point which we can improve? 


TLS 1.3 decided to abandon all such variants because they do not provide forward secrecy, but I suppose it reasonable to revisit that decision in the context of a constrained environment. 

[GS] All four methods do provide forward secrecy according to the security analysis papers (see below). Static DH authenticated ephemeral DH is also used elsewhere, for example, the Noise XX pattern, which is similar to method 3. TLS 1.3 unfortunately did not abandon all variants that do not provide forward secrecy; psk-ke is even marked as “Recommended”; a decision that is proposed to be revisited in https://datatracker.ietf.org/doc/draft-mattsson-tls-psk-ke-dont-dont-dont/ <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-dde73b40fccabc36&amp;q=1&amp;e=796763d1-d3a7-40d6-a1f3-e2af5448b2cf&amp;u=https%3A%2F%2Feur05.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-mattsson-tls-psk-ke-dont-dont-dont%252F%26data%3D05%257C01%257Cmarco.tiloca%2540ri.se%257C0573e835d4604c96a0ff08daff2d8689%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C638102868263280565%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26sdata%3DC7ofNVNFb6jedCIIziwq0n2BWiHYFU4XR6mOza%252FD3Wc%253D%26reserved%3D0>. 


But I can think of no justification for the misleading name. The working group name (Lightweight Authenticated Key Exchange - LAKE) would be a more accurately descriptive name. 

[GS] That particular name change has actually been discussed and, at the time, was not preferred: https://mailarchive.ietf.org/arch/msg/lake/2uuzP5T2ijkYEMsbqzt03200U2s/ <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-35e29c81f9a59eeb&amp;q=1&amp;e=796763d1-d3a7-40d6-a1f3-e2af5448b2cf&amp;u=https%3A%2F%2Feur05.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fmailarchive.ietf.org%252Farch%252Fmsg%252Flake%252F2uuzP5T2ijkYEMsbqzt03200U2s%252F%26data%3D05%257C01%257Cmarco.tiloca%2540ri.se%257C0573e835d4604c96a0ff08daff2d8689%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C638102868263280565%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26sdata%3DD4NU3UNH8hkurB1UFgHF9ENNtm8e0R9hHK5T4mk%252BjDo%253D%26reserved%3D0> 


The authors may be confused about the definition of forward secrecy, since in Security Considerations they say this protocol provides forward secrecy and in Appendix J they refer to a key refresh technique that has some nice security properties but does not provide what is generally regarded as forward secrecy. 

[GS] All methods in the protocol do provide forward secrecy with respect to long term keys. Compromise of the long-term keys does not compromise session keys from previous connections. Compromise of one session key does not compromise old session keys in the same connection. The method of obtaining forward secrecy through iterated key derivation was introduced in LAKE by Karthik Bargavan: https://mailarchive.ietf.org/arch/msg/lake/-Fx-NVLrZohQ7p8Wy8VNpsDC_-M/ <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-e586f3ec064c471f&amp;q=1&amp;e=796763d1-d3a7-40d6-a1f3-e2af5448b2cf&amp;u=https%3A%2F%2Feur05.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fmailarchive.ietf.org%252Farch%252Fmsg%252Flake%252F-Fx-NVLrZohQ7p8Wy8VNpsDC_-M%252F%26data%3D05%257C01%257Cmarco.tiloca%2540ri.se%257C0573e835d4604c96a0ff08daff2d8689%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C638102868263280565%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26sdata%3DUh%252BBglhnRxoREWuN4wxL0wFYLzvjxxObpDSa%252FZmzWMI%253D%26reserved%3D0> 
Appendix J does not include a protocol since the WG decided this draft to focus on the public key authenticated ephemeral Diffie-Hellman, but the high level solution in Appendix J is the same as the key update in TLS 1.3 and RFC 8446 states that this mechanism provides forward secrecy. 


Other differences: 

They simplify the protocol compared to TLS by not including the variations allowing restart of a security context based on cached information. While this makes the code to implement the protocol simpler, it hurts performance. 

[GS] A resumption option with ephemeral DH would have roughly the same message size but would only require one Diffie-Hellman operation compared to three in full EDHOC. In many constrained radio environments message sizes are the most important parameter for performance. One perhaps more important reason to define a resumption option is that fetching credentials from a database, validating them, and doing revocation is slow. 
Variations of resumption for EDHOC, to specify in a companying document, is for discussion; one recent email on the topic: https://mailarchive.ietf.org/arch/msg/lake/sMUlR-8eOe5ZalCNpsQS69hlCc0/ <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-6fbf754a9d4c2cb9&amp;q=1&amp;e=796763d1-d3a7-40d6-a1f3-e2af5448b2cf&amp;u=https%3A%2F%2Feur05.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fmailarchive.ietf.org%252Farch%252Fmsg%252Flake%252FsMUlR-8eOe5ZalCNpsQS69hlCc0%252F%26data%3D05%257C01%257Cmarco.tiloca%2540ri.se%257C0573e835d4604c96a0ff08daff2d8689%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C638102868263438017%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26sdata%3DQfnBKi%252B6Wxz%252Flsw4H198QWprvOy5hG6OcEpYjHZZaos%253D%26reserved%3D0> 
There is also the KUDOS draft which provides updates on the OSCORE security context without using EDHOC: 
https://datatracker.ietf.org/doc/draft-ietf-core-oscore-key-update/ <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-b880b524e64ed23e&amp;q=1&amp;e=796763d1-d3a7-40d6-a1f3-e2af5448b2cf&amp;u=https%3A%2F%2Feur05.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-ietf-core-oscore-key-update%252F%26data%3D05%257C01%257Cmarco.tiloca%2540ri.se%257C0573e835d4604c96a0ff08daff2d8689%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C638102868263447958%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26sdata%3Di2%252F9Gi9fwXvleTCJ2V%252Ffllklk2lUmsv9bqXkoKQKgjk%253D%26reserved%3D0> 


The negotiation of cryptographic algorithms is based on suites (as early versions of TLS did) rather than a more ala carte approach that TLS has evolved towards. Further, while TLS has a system of initiator proposes and responder chooses cryptographic algorithms, in EDHOC's system the responder is constrained to choose the most preferred of the initiator's suites that it supports. Further, the initiator must guess the suite the responder will choose and the protocol may be very "chatty" the first time the protocol is run (or every time if the initiator does not cache the preferred suite of the responder). There would be an extra pair of messages for each suite the initiator prefers over the first one the responder accepts. 

[GS] One common setup for IoT devices is that there are only one or a few supported algorithms, and that supported algorithm is known at the time of deployment, in which case there is less risk for chatty negotiation. Regarding caching of cipher suites, 6.3.1 notes that ”After a successful run of EDHOC, the Initiator MAY remember the selected cipher suite to use in future EDHOC sessions.” 
With such setup we believe it should be possible to avoid too much chattiness. Happy for further input. 


Whether authentication is going to be based on Ephemeral or Static Diffie-Hellman keys is not negotiated. The initiator is expected to know (or the protocol gets more chatty). 

[GS] Negotation of method has been discussed in the WG. It could be included in the same low overhead proccedure as negotiation of cipher suite. But like the common case for cipher suites above it is expected that constrained devices only support a single method which is known at deployment time, so it is not clear that negotiation is needed for the most constrained settings (or a significant overhead in less constrained settings). 


Finally, rather than negotiating a symmetric encryption algorithm for use within EDHOC itself, EDHOC generates an extended PRF output which it XORs into messages to encrypt them. In practice, this strikes me as a clever hack to greatly simpify the specification while not substantially hurting performance. But others may disagree. 

There was a reference to an analysis of the security of the protocol (which is based on SIGMA). I didn't read it, but the design of the protocol looks sound to me. 

[GS] Just a note: We have updated the list of security analysis papers we are aware of and which we have taken into account (Section 8.1) and there are now 5 publications analysing different methods of the protocol using different techniques: [Bruni18] [Norrman20] [CottierPointcheval22] [Jacomme23] [GuentherIlunga22], see 
https://lake-wg.github.io/edhoc/draft-ietf-lake-edhoc.html#name-security-properties <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-863422f1b3a5a14d&amp;q=1&amp;e=796763d1-d3a7-40d6-a1f3-e2af5448b2cf&amp;u=https%3A%2F%2Feur05.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fprotect2.fireeye.com%252Fv1%252Furl%253Fk%253D31323334-501d5122-313273af-454445555731-81c5b24e4d1baec7%2526q%253D1%2526e%253D427745ef-5c95-47a0-829a-3e732e155bd9%2526u%253Dhttps%25253A%25252F%25252Flake-wg.github.io%25252Fedhoc%25252Fdraft-ietf-lake-edhoc.html%252523name-security-properties%26data%3D05%257C01%257Cmarco.tiloca%2540ri.se%257C0573e835d4604c96a0ff08daff2d8689%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C638102868263448691%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26sdata%3DwSDDdk%252FHFeW8vTRkAV2DA0Ne543Yr%252F2T3auOCWPgI7w%253D%26reserved%3D0> 

Nits: 

>From Section 1.1: 

"This specification emphasizes the possibility to reference 
rather than to transport credentials in order to reduce message 
overhead, but the latter is also supported." 

-> 

"This specification supports the referencing of credentials in order to reduce message 
overhead, but credentials may alternatively be embedded." 

[GS] Done. 

In Section 3.9: 

"incompliance" -> "non-compliance" 

[GS] Based on a previous comment we already changed this to ”lack of compliance”. 

Thanks, 
Göran 









-- Marco Tiloca Ph.D., Senior Researcher Phone: [phone] RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3d296ae5721cac2b&amp;q=1&amp;e=796763d1-d3a7-40d6-a1f3-e2af5448b2cf&amp;u=https%3A%2F%2Fwww.ri.se%2F>