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

[Marco Tiloca <[e-mail]>]

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-ephemeralinstead?
>
> - 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/

[1] 
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/

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

<==

>
> Cheers,
>
> John
>
> *From: *Göran Selander <[e-mail]>
> *Date: *Wednesday, 25 January 2023 at 23:21
> *To: *Radia Perlman <[e-mail]>, [e-mail] 
> <[e-mail]>, The IESG <[e-mail]>, 
> [e-mail] 
> <[e-mail]>, [e-mail] <[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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-501d5122-313273af-454445555731-bb10ca2ae3c3bf76%26q%3D1%26e%3D427745ef-5c95-47a0-829a-3e732e155bd9%26u%3Dhttps%253A%252F%252Fgithub.com%252Flake-wg%252Fedhoc%252Fpull%252F395&data=05%7C01%7Cmarco.tiloca%40ri.se%7C0573e835d4604c96a0ff08daff2d8689%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638102868263280565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QPfvjZ5MyHzkY53BWuY%2B9XsCfScb2HYJif2aBo69Y4E%3D&reserved=0>
>
> From: Radia Perlman <[e-mail]> 
> <mailto:&lt;[e-mail]&gt;>
>
> Date: Tuesday, 24 January 2023 at 03:49
>
> To: [e-mail] <mailto:[e-mail]> <[e-mail]> 
> <mailto:&lt;[e-mail]&gt;>, The IESG <[e-mail]> 
> <mailto:&lt;[e-mail]&gt;>, [e-mail] 
> <mailto:[e-mail]> 
> <[e-mail]> 
> <mailto:&lt;[e-mail]&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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mattsson-tls-psk-ke-dont-dont-dont%2F&data=05%7C01%7Cmarco.tiloca%40ri.se%7C0573e835d4604c96a0ff08daff2d8689%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638102868263280565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=C7ofNVNFb6jedCIIziwq0n2BWiHYFU4XR6mOza%2FD3Wc%3D&reserved=0>.
>
> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Flake%2F2uuzP5T2ijkYEMsbqzt03200U2s%2F&data=05%7C01%7Cmarco.tiloca%40ri.se%7C0573e835d4604c96a0ff08daff2d8689%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638102868263280565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D4NU3UNH8hkurB1UFgHF9ENNtm8e0R9hHK5T4mk%2BjDo%3D&reserved=0>
>
> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Flake%2F-Fx-NVLrZohQ7p8Wy8VNpsDC_-M%2F&data=05%7C01%7Cmarco.tiloca%40ri.se%7C0573e835d4604c96a0ff08daff2d8689%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638102868263280565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Uh%2BBglhnRxoREWuN4wxL0wFYLzvjxxObpDSa%2FZmzWMI%3D&reserved=0>
>
> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Flake%2FsMUlR-8eOe5ZalCNpsQS69hlCc0%2F&data=05%7C01%7Cmarco.tiloca%40ri.se%7C0573e835d4604c96a0ff08daff2d8689%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638102868263438017%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QfnBKi%2B6Wxz%2Flsw4H198QWprvOy5hG6OcEpYjHZZaos%3D&reserved=0>
>
> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-oscore-key-update%2F&data=05%7C01%7Cmarco.tiloca%40ri.se%7C0573e835d4604c96a0ff08daff2d8689%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638102868263447958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=i2%2F9Gi9fwXvleTCJ2V%2Ffllklk2lUmsv9bqXkoKQKgjk%3D&reserved=0>
>
> 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 
> systemthe 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-501d5122-313273af-454445555731-81c5b24e4d1baec7%26q%3D1%26e%3D427745ef-5c95-47a0-829a-3e732e155bd9%26u%3Dhttps%253A%252F%252Flake-wg.github.io%252Fedhoc%252Fdraft-ietf-lake-edhoc.html%2523name-security-properties&data=05%7C01%7Cmarco.tiloca%40ri.se%7C0573e835d4604c96a0ff08daff2d8689%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638102868263448691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wSDDdk%2FHFeW8vTRkAV2DA0Ne543Yr%2F2T3auOCWPgI7w%3D&reserved=0>
>
> 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