Subject: Re: [Secdispatch] [Ace] EDHOC

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 4 Feb 2019 12:30:20 -0500

Will there be an interim for this topic?

Thank you,
Kathleen

On Thu, Jan 24, 2019 at 2:15 PM Kathleen Moriarty <
[email-masked]> wrote:

> Thanks for the very helpful message, Goran.  A couple of comments inline.
>
> On Thu, Jan 24, 2019 at 11:31 AM Göran Selander <
> [email-masked]> wrote:
>
>> Hi Richard, Roman, all
>>
>>
>>
>> Thanks for kind welcome and for progressing the discussion. Apologies for
>> a long email.
>>
>>
>>
>> *From: *Richard Barnes <[email-masked]>
>>
>>
>>
>> Summing up where I believe the conversation stands now, it seems like
>> what folks are asking for is either:
>>
>>
>>
>>    1. An analysis that shows that EDHOC is equivalent to an existing AKE
>>    (e.g., IKE or TLS), or
>>
>>
>>
>> 2. An argument that a new AKE is necessary (vs. a re-encoding of an
>> existing AKE)
>>
>>
>>
>> Göran et al: Do you have thoughts on those points?
>>
>>
>>
>> Yes. I’ll get back to this later in this email.
>>
>>
>>
>> It seems like it could be a productive use of an hour or two of virtual
>> interim time to help the group understand one of those lines of argument.
>>
>>
>>
>> Agree.
>>
>
> Anything to prevent further hold ups on this work would be appreciated.
>
>
>>
>>
>> --Richard
>>
>>
>>
>> As requested in a previous email, here is a background.
>>
>>
>>
>> The work on EDHOC is motivated by the need for an authentication and key
>> exchange protocol for OSCORE (draft-ietf-core-object-security) optimized
>> for constrained-node networks (RFC 7228). OSCORE is applied within the
>> IETF, e.g. in 6TiSCH minimal security (draft-ietf-6tisch-minimal-security),
>> but also requested by other SDOs and industry fora such as OMA Specworks,
>> Open Connectivity Foundation and Fairhair Alliance. The properties of
>> OSCORE motivating its use include: support for CoAP forward proxies,
>> support for change of underlying transports including non-IP, low overhead,
>> low additional footprint and memory to existing CoAP implementations,
>> support for multicast security, security for end-to-end REST.
>>
>>
>>
>> Given the large interest in OSCORE already before it has become an RFC we
>> anticipate a wide range of deployments. For example, we see an interest for
>> OSCORE in Cellular IoT with traffic running over the cellular air interface
>> control channel, where we can have end-to-end CoAP, but not necessarily
>> end-to-end IP between an application server and a cellular device. Or
>> between an application server and a device behind a cellular gateway.
>> Comparing just these two cases, the difference in capabilities of the
>> devices can be significant which makes it difficult to point at some sort
>> of “reference devices” for benchmarking.
>>
>>
>>
>> In order to support the low end use cases the AKE must be performant in
>> low bandwidth deployments with battery powered devices restricted in RAM
>> and ROM. Message sizes and round trips have a direct impact on latency,
>> power consumption and battery lifetime, and can be calculated which is the
>> reason for this being a commonly used metric. While it may be more
>> difficult to compare memory and storage requirements, the ability to reuse
>> existing code is an important indication. If a device can support a CoAP
>> stack (in the sense of memory and flash, etc) it is expected to also be
>> able to support OSCORE. Similarly, it is desirable that a device with CoAP
>> and OSCORE implemented should be able to support an additional AKE.
>> Considering that EDHOC reuses CBOR and COSE primitives from OSCORE the
>> additional code for EDHOC can be very limited.
>>
>>
>>
>> From a security point of view OSCORE requires that the endpoints have
>> agreed on a Master Secret with a good amount of randomness, and each
>> other’s Sender IDs, and those must be different for a given Master Secret.
>>
>>
>>
>> Now returning to the questions.
>>
>>
>>
>>    1. An analysis that shows that EDHOC is equivalent to an existing AKE
>>    (e.g., IKE or TLS)
>>
>>
>>
>> Considering EDHOC is a new protocol it should be thoroughly analysed and
>> verified against all currently known issues of AKEs. Roman sent a mail to
>> the secdispatch list referencing a paper presented at SSR 2018 which could
>> be used as a starting point. How do folks want to digest this: Do they want
>> to study the model themselves or should we ask the authors if they could
>> present their work at the interim?
>>
>>
>>
>> 2. An argument that a new AKE is necessary (vs. a re-encoding of an
>> existing AKE)
>>
>>
>>
>> We have done this comparison with TLS/DTLS for some time now, and what
>> once seemed like a reasonable question has turned out to be never ending
>> exercise. I do not want to get into IETF archeology but for those who have
>> not followed the discussion some data points could be relevant.
>>
>>
>>
>> Not long ago, the design of security protocols did not take into account
>> constrained IoT devices. With OSCORE we showed that the message overhead
>> could be reduced by a factor 3 compared to DTLS 1.2 records. Before this
>> comparison it was believed that the record layer was performing well, then
>> the difference in overhead was characterized as insignificant, and then
>> finally a compact format was designed for DTLS 1.3.
>>
>>
>>
>> With EDHOC we showed that the message overhead of the key exchange can be
>> reduced with up to a factor 4 compared to the current version of DTLS 1.3
>> (see Appendix E in EDHOC). Before this exercise it was believed that the
>> TLS/DTLS handshake was performing well, then the difference in overhead was
>> characterized as insignificant, and now the discussion has shifted to
>> downsizing the TLS handshake or other protocol.
>>
>>
>>
>> We are not against optimizations to the TLS handshake, just as we welcome
>> the more optimal DTLS 1.3 records. But TLS was not designed to be an AKE
>> for OSCORE optimized for constrained environments. As I remember,
>> optimizing for message overhead was an explicit non-requirement of TLS 1.3.
>> Reverting those design decisions seems like the wrong way to go: One reason
>> to use TLS would be to reuse an existing implementation. But existing TLS
>> implementation would most likely not compare favorably in terms of code
>> size and RAM. Adding code for compression or re-encoding of the messages
>> would add to that. Re-specifying the protocol with the new encoding may
>> require a new formal verification. To make a more compact code and
>> processing may involve two incompatible message formats of TLS depending on
>> what is being signed. New implementations would be needed.
>>
>>
>>
>> We think we have done our part of the comparison exercise and that the
>> burden of proof should now be reversed. Could we ask those that claim to
>> have a more performant key exchange protocol for OSCORE and are prepared to
>> do the work to make that plausible and provide the numbers? To be clear: if
>> there is another key exchange protocol suitable for OSCORE which
>> outperforms EDHOC in constrained characteristics and then we are very
>> interested.
>>
>
> I agree with Goran that they have jumped through enough hoops at this
> point.  However, if alternatives come forward, understanding their
> timelines is also critical as not to hold up this work for any substantial
> amount of time.
>
>
>>
>> And again, with the statements in this mail we neither want to belittle
>> the considerable effort made on formal verification, nor claim that DTLS is
>> not fit for IoT deployments. It is an important hammer in our IoT security
>> toolbox, but at the moment we don’t need a hammer.
>>
>
> The class of IoT device seems to be the critical point here and having one
> protocol that can meet all needs is a nice goal, but not realistic from the
> comparison numbers provided and the varying requirements in the IoT space.
>
> Best regards,
> Kathleen
>
>
>>
>>
>>
>> Göran
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Ace mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ace
>>
>
>
> --
>
> Best regards,
> Kathleen
>

-- 

Best regards,
Kathleen

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 11 Feb 2019 23:13:10 +0000

Hi Kathleen!

Yes.  A doodle poll to determine the most agreeable time the week of March 4 was just sent:

https://mailarchive.ietf.org/arch/msg/secdispatch/KU3SWW_4UeJ9JMH9abmzaKeXXgc

Roman

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Monday, February 04, 2019 12:30 PM
To: Göran Selander <[email-masked]>
Cc: Richard Barnes <[email-masked]>; Roman Danyliw <[email-masked]>; John Mattsson <[email-masked]>; [email-masked]; Francesca Palombini <[email-masked]>; [email-masked]
Subject: Re: [Ace] [Secdispatch] EDHOC

Thank you,
Kathleen

On Thu, Jan 24, 2019 at 2:15 PM Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the very helpful message, Goran.  A couple of comments inline.

On Thu, Jan 24, 2019 at 11:31 AM Göran Selander <[email-masked]<mailto:[email-masked]>> wrote:
Hi Richard, Roman, all

Thanks for kind welcome and for progressing the discussion. Apologies for a long email.

From: Richard Barnes <[email-masked]<mailto:[email-masked]>>

Summing up where I believe the conversation stands now, it seems like what folks are asking for is either:

1.      An analysis that shows that EDHOC is equivalent to an existing AKE (e.g., IKE or TLS), or

2. An argument that a new AKE is necessary (vs. a re-encoding of an existing AKE)

It seems like it could be a productive use of an hour or two of virtual interim time to help the group understand one of those lines of argument.

Agree.

--Richard

The work on EDHOC is motivated by the need for an authentication and key exchange protocol for OSCORE (draft-ietf-core-object-security) optimized for constrained-node networks (RFC 7228). OSCORE is applied within the IETF, e.g. in 6TiSCH minimal security (draft-ietf-6tisch-minimal-security), but also requested by other SDOs and industry fora such as OMA Specworks, Open Connectivity Foundation and Fairhair Alliance. The properties of OSCORE motivating its use include: support for CoAP forward proxies, support for change of underlying transports including non-IP, low overhead, low additional footprint and memory to existing CoAP implementations, support for multicast security, security for end-to-end REST.

Given the large interest in OSCORE already before it has become an RFC we anticipate a wide range of deployments. For example, we see an interest for OSCORE in Cellular IoT with traffic running over the cellular air interface control channel, where we can have end-to-end CoAP, but not necessarily end-to-end IP between an application server and a cellular device. Or between an application server and a device behind a cellular gateway. Comparing just these two cases, the difference in capabilities of the devices can be significant which makes it difficult to point at some sort of “reference devices” for benchmarking.

In order to support the low end use cases the AKE must be performant in low bandwidth deployments with battery powered devices restricted in RAM and ROM. Message sizes and round trips have a direct impact on latency, power consumption and battery lifetime, and can be calculated which is the reason for this being a commonly used metric. While it may be more difficult to compare memory and storage requirements, the ability to reuse existing code is an important indication. If a device can support a CoAP stack (in the sense of memory and flash, etc) it is expected to also be able to support OSCORE. Similarly, it is desirable that a device with CoAP and OSCORE implemented should be able to support an additional AKE. Considering that EDHOC reuses CBOR and COSE primitives from OSCORE the additional code for EDHOC can be very limited.

From a security point of view OSCORE requires that the endpoints have agreed on a Master Secret with a good amount of randomness, and each other’s Sender IDs, and those must be different for a given Master Secret.

1.      An analysis that shows that EDHOC is equivalent to an existing AKE (e.g., IKE or TLS)

Considering EDHOC is a new protocol it should be thoroughly analysed and verified against all currently known issues of AKEs. Roman sent a mail to the secdispatch list referencing a paper presented at SSR 2018 which could be used as a starting point. How do folks want to digest this: Do they want to study the model themselves or should we ask the authors if they could present their work at the interim?

2. An argument that a new AKE is necessary (vs. a re-encoding of an existing AKE)

We have done this comparison with TLS/DTLS for some time now, and what once seemed like a reasonable question has turned out to be never ending exercise. I do not want to get into IETF archeology but for those who have not followed the discussion some data points could be relevant.

Not long ago, the design of security protocols did not take into account constrained IoT devices. With OSCORE we showed that the message overhead could be reduced by a factor 3 compared to DTLS 1.2 records. Before this comparison it was believed that the record layer was performing well, then the difference in overhead was characterized as insignificant, and then finally a compact format was designed for DTLS 1.3.

With EDHOC we showed that the message overhead of the key exchange can be reduced with up to a factor 4 compared to the current version of DTLS 1.3 (see Appendix E in EDHOC). Before this exercise it was believed that the TLS/DTLS handshake was performing well, then the difference in overhead was characterized as insignificant, and now the discussion has shifted to downsizing the TLS handshake or other protocol.

We are not against optimizations to the TLS handshake, just as we welcome the more optimal DTLS 1.3 records. But TLS was not designed to be an AKE for OSCORE optimized for constrained environments. As I remember, optimizing for message overhead was an explicit non-requirement of TLS 1.3. Reverting those design decisions seems like the wrong way to go: One reason to use TLS would be to reuse an existing implementation. But existing TLS implementation would most likely not compare favorably in terms of code size and RAM. Adding code for compression or re-encoding of the messages would add to that. Re-specifying the protocol with the new encoding may require a new formal verification. To make a more compact code and processing may involve two incompatible message formats of TLS depending on what is being signed. New implementations would be needed.

We think we have done our part of the comparison exercise and that the burden of proof should now be reversed. Could we ask those that claim to have a more performant key exchange protocol for OSCORE and are prepared to do the work to make that plausible and provide the numbers? To be clear: if there is another key exchange protocol suitable for OSCORE which outperforms EDHOC in constrained characteristics and then we are very interested.

I agree with Goran that they have jumped through enough hoops at this point.  However, if alternatives come forward, understanding their timelines is also critical as not to hold up this work for any substantial amount of time.

And again, with the statements in this mail we neither want to belittle the considerable effort made on formal verification, nor claim that DTLS is not fit for IoT deployments. It is an important hammer in our IoT security toolbox, but at the moment we don’t need a hammer.

The class of IoT device seems to be the critical point here and having one protocol that can meet all needs is a nice goal, but not realistic from the comparison numbers provided and the varying requirements in the IoT space.

Best regards,
Kathleen

Göran

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

--

Best regards,
Kathleen

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 11 Feb 2019 19:29:53 -0500

If I’m reading it correctly, it looks like I will be speaking at RSA during that time slot.  Can the recording be posted?  It’s a tough week for anyone attending, so I suspect attendance will be impacted.

Thank you,
Kathleen 

Sent from my mobile device

> On Feb 11, 2019, at 6:13 PM, Roman Danyliw <[email-masked]> wrote:
> 
> Hi Kathleen!
>  
> On Thu, Jan 24, 2019 at 2:15 PM Kathleen Moriarty <[email-masked]> wrote:
> On Thu, Jan 24, 2019 at 11:31 AM Göran Selander <[email-masked]> wrote:
> Hi Richard, Roman, all
>  
> From: Richard Barnes <[email-masked]>
> 
>

---

From: Bret Jordan <[email-masked]>
Date: Mon, 11 Feb 2019 18:42:14 -0700

Yes, doing anything during the week of RSA is a significant challenge. 

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Feb 11, 2019, at 5:29 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> On Feb 11, 2019, at 6:13 PM, Roman Danyliw <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi Kathleen!
>>  
>> https://mailarchive.ietf.org/arch/msg/secdispatch/KU3SWW_4UeJ9JMH9abmzaKeXXgc <https://mailarchive.ietf.org/arch/msg/secdispatch/KU3SWW_4UeJ9JMH9abmzaKeXXgc>
>>  
>> Roman
>>  
>>  
>> From: Kathleen Moriarty [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Göran Selander <[email-masked] <mailto:goran.selander@ericsson..com>>
>> Cc: Richard Barnes <[email-masked] <mailto:[email-masked]>>; Roman Danyliw <[email-masked] <mailto:[email-masked]>>; John Mattsson <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Francesca Palombini <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> On Thu, Jan 24, 2019 at 2:15 PM Kathleen Moriarty <[email-masked] <mailto:[email-masked]>> wrote:
>> On Thu, Jan 24, 2019 at 11:31 AM Göran Selander <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Richard, Roman, all
>>  
>> From: Richard Barnes <[email-masked] <mailto:[email-masked]>>
>> 
>>  
>> 1..      An analysis that shows that EDHOC is equivalent to an existing AKE (e.g., IKE or TLS), or
>>  
>> 1..      An analysis that shows that EDHOC is equivalent to an existing AKE (e.g., IKE or TLS)
>>  
>> Not long ago, the design of security protocols did not take into account constrained IoT devices. With OSCORE we showed that the message overhead could be reduced by a factor 3 compared to DTLS 1..2 records. Before this comparison it was believed that the record layer was performing well, then the difference in overhead was characterized as insignificant, and then finally a compact format was designed for DTLS 1.3.
>> 
>>  
>> 
>> We are not against optimizations to the TLS handshake, just as we welcome the more optimal DTLS 1.3 records. But TLS was not designed to be an AKE for OSCORE optimized for constrained environments.. As I remember, optimizing for message overhead was an explicit non-requirement of TLS 1.3. Reverting those design decisions seems like the wrong way to go: One reason to use TLS would be to reuse an existing implementation. But existing TLS implementation would most likely not compare favorably in terms of code size and RAM. Adding code for compression or re-encoding of the messages would add to that. Re-specifying the protocol with the new encoding may require a new formal verification. To make a more compact code and processing may involve two incompatible message formats of TLS depending on what is being signed. New implementations would be needed.
>> 
>>  
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ace <https://www.ietf.org/mailman/listinfo/ace>
>> 
>>  
>> -- 
>>  
>> Best regards,
>> Kathleen
>> 
>>  
>> -- 
>>  
>> Best regards,
>> Kathleen
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 13 Feb 2019 00:14:22 +0000

Hi Kathleen!

There are multiple slots offered during the week of March 4 as possible times for the meeting.  Perhaps one of them doesn’t conflict?

Yes, we’ll record it.  We appreciate everyone’s flexibility given the conflict with RSA.

Roman

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Monday, February 11, 2019 7:30 PM
To: Roman Danyliw <[email-masked]>
Cc: Richard Barnes <[email-masked]>; John Mattsson <[email-masked]>; [email-masked]; Francesca Palombini <[email-masked]>; [email-masked]; Göran Selander <[email-masked]>
Subject: Re: [Ace] [Secdispatch] EDHOC

Thank you,
Kathleen

On Feb 11, 2019, at 6:13 PM, Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kathleen!

Roman

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Monday, February 04, 2019 12:30 PM
To: Göran Selander <[email-masked]<mailto:[email-masked]>>
Cc: Richard Barnes <[email-masked]<mailto:[email-masked]>>; Roman Danyliw <[email-masked]<mailto:[email-masked]>>; John Mattsson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Francesca Palombini <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] [Secdispatch] EDHOC

Thank you,
Kathleen

Agree.

--Richard

Best regards,
Kathleen

Göran

--

Best regards,
Kathleen

--

Best regards,
Kathleen

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 28 Feb 2019 15:27:16 +0000

> -----Original Message-----
> From: Roman Danyliw
> Sent: Tuesday, January 22, 2019 6:10 PM
> To: [email-masked]
> Cc: Francesca Palombini <[email-masked]>; John
> Mattsson <[email-masked]>; 'Göran Selander'
> <[email-masked]>
> Subject: RE: EDHOC
> 
> Hi!
> 
> > -----Original Message-----
> > From: Secdispatch [mailto:[email-masked]] On Behalf Of
> > Göran Selander
> > Sent: Wednesday, January 02, 2019 5:56 PM
> > To: [email-masked]
> > Cc: Francesca Palombini <[email-masked]>; John
> > Mattsson <[email-masked]>
> > Subject: [Secdispatch] EDHOC
> >
> > We have been advised to ask secdispatch to consider EDHOC:
> > https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe
> 
> [snip]
> 
> > There has been a number of reviews of different versions of the draft;
> > both by people who want to deploy it and by people analysing the
> > security. A formal verification was presented at SSR 2018.
> 
> To save others the search time, I believe this is the reference on a formal
> verification of EDHOC:
> 
> Bruni A., Sahl Jørgensen T., Grønbech Petersen T., Schürmann C. (2018)
> Formal Verification of Ephemeral Diffie-Hellman Over COSE (EDHOC). In:
> Cremers C., Lehmann A. (eds) Security Standardisation Research. SSR 2018.
> Lecture Notes in Computer Science, vol 11322. Springer, Cham
> 
> https://link.springer.com/content/pdf/10.1007%2F978-3-030-04762-7_2.pdf

The following is an alternate reference to this paper that isn't behind a paywall (thanks to one of the paper's authors, Alessandro Bruni):

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

Additionally, the model associated with this paper can be found here:

https://github.com/theisgroenbech/edhoc-proverif

Roman