Subject: Re: [Ace] [Secdispatch] EDHOC

From: Göran Selander <[email-masked]>
Date: Fri, 4 Jan 2019 06:17:27 +0000

Hi Kathleen,

Good question. Thanks for bringing continuity to this almost 2 years long offline discussion. Indeed, lack of comparison with other protocols and formal verification were at the time the arguments for not following up the in-room consensus with an email confirmation. And, as you noted, that is not the case anymore.

Meanwhile the ACE chairs and AD have changed. My understanding is that the argument now is about attracting more people with a certain security competence for which perhaps another WG could potentially be better, hence the request to Secdispatch. But I'll pass the question on and include the ACE WG for transparency.

From the authors' humble point of view we believe that the main missing thing that would enable the required further discussion is that the IETF endorses this work, no matter how, so that people dare invest more time in implementation and analysis. 

Best regards,
Göran

On 2019-01-03, 00:58, "Kathleen Moriarty" <[email-masked]> wrote:

    Hi,
    
    I’ve read earlier versions of this draft and appreciate all the work you have done with the security proof and comparing to existing standardized protocols.  If ACE is interested, why is this going to SECDispatch? It might help to understand that better.  Is it that a recharter would be needed?
    
    Thank you & happy new year!
    Kathleen 
    
    Sent from my mobile device
    
    > On Jan 2, 2019, at 5:56 PM, Göran Selander <[email-masked]> wrote:
    > 
    > Dear Secdispatch,
    > 
    > We have been advised to ask secdispatch to consider EDHOC: https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe
    > 
    > Those that follow the ACE WG should be familiar with this draft. The problem statement and motivation for EDHOC is described in section 1. In brief, the target is a lightweight key exchange protocol suitable for IoT applications, which:
    > a) has small message size and reuses existing IoT primitives to enable low overhead and small code footprint; 
    > b) is not bound to a particular transport, to enable end-to-end security in IoT deployments with varying underlying layers; and
    > c) can be used to key OSCORE (draft-ietf-core-object-security) that is lacking a harmonizing key exchange protocol.
    > 
    > These requirements are motivated by constrained IoT device deployments, but the protocol is applicable to other end-to-end security settings where the overhead due to security needs to be low. EDHOC addresses these requirements and builds on the SIGMA construction for Diffie-Hellman key exchanges. EDHOC, like OSCORE, is built on CBOR (RFC 7049) and COSE (RFC 8152) and the protocol messages may be transported with CoAP (RFC 7252).  
    > 
    > 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. There are a few implementations of different versions of the draft. The ACE WG has expressed interest in this work in several f2f meetings.
    > 
    > Please let us know if some information is missing for secdispatch to consider this draft, or how we can help out in the process.
    > 
    > Best regards
    > Göran, John, Francesca
    > 
    > 
    > _______________________________________________
    > Secdispatch mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Richard Barnes <[email-masked]>
Date: Fri, 18 Jan 2019 11:54:58 -0500

Let me provide some additional context.  When the chairs and ADs discussed this in BKK, it seemed pretty clear that EDHOC is not within the current charter of ACE — after all, ACE is targeted at authentication and authorization, not key exchange.  Since ACE would need to recharter to accept this work in any case, and because EDHOC overlapped with the interests of other working groups, it seemed to make sense to have the conversation in a broader venue.

Göran: Your email starting this thread seems like an abbreviated summary of the past discussion of this draft.  Since this is a new audience, it would be helpful if you could start from the underlying requirements (“we need an AKE with certain constraints”) and lay out why new protocol work is needed, vs. profiling existing protocols (as has been done, e.g., in DICE).

If it would be helpful to keep this moving, we could certainly arrange a virtual interim on this topic.

—Richard

> On Jan 4, 2019, at 1:17 AM, Göran Selander <[email-masked]> wrote:
> 
> Hi Kathleen,
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 18 Jan 2019 12:06:40 -0500

Can that be a public thread?  It really should be.

> On Jan 18, 2019, at 11:54 AM, Richard Barnes <[email-masked]> wrote:
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 18 Jan 2019 12:12:03 -0500

Not sure what you mean, Kathleen.  This is a public mailing list :)

On Fri, Jan 18, 2019 at 12:06 PM Kathleen Moriarty <
[email-masked]> wrote:

> > Let me provide some additional context.  When the chairs and ADs
> discussed this in BKK, it seemed pretty clear that EDHOC is not within the
> current charter of ACE — after all, ACE is targeted at authentication and
> authorization, not key exchange.  Since ACE would need to recharter to
> accept this work in any case, and because EDHOC overlapped with the
> interests of other working groups, it seemed to make sense to have the
> conversation in a broader venue.
> >
> > Göran: Your email starting this thread seems like an abbreviated summary
> of the past discussion of this draft.  Since this is a new audience, it
> would be helpful if you could start from the underlying requirements (“we
> need an AKE with certain constraints”) and lay out why new protocol work is
> needed, vs. profiling existing protocols (as has been done, e.g., in DICE).
> >
> >> Good question. Thanks for bringing continuity to this almost 2 years
> long offline discussion. Indeed, lack of comparison with other protocols
> and formal verification were at the time the arguments for not following up
> the in-room consensus with an email confirmation. And, as you noted, that
> is not the case anymore.
> >>
> >> Meanwhile the ACE chairs and AD have changed. My understanding is that
> the argument now is about attracting more people with a certain security
> competence for which perhaps another WG could potentially be better, hence
> the request to Secdispatch. But I'll pass the question on and include the
> ACE WG for transparency.
> >>
> >> From the authors' humble point of view we believe that the main missing
> thing that would enable the required further discussion is that the IETF
> endorses this work, no matter how, so that people dare invest more time in
> implementation and analysis.
> >>
> >> Best regards,
> >> Göran
> >>
> >>
> >>   I’ve read earlier versions of this draft and appreciate all the work
> you have done with the security proof and comparing to existing
> standardized protocols.  If ACE is interested, why is this going to
> SECDispatch? It might help to understand that better.  Is it that a
> recharter would be needed?
> >>
> >>> We have been advised to ask secdispatch to consider EDHOC:
> https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe
> >>>
> >>> Those that follow the ACE WG should be familiar with this draft. The
> problem statement and motivation for EDHOC is described in section 1. In
> brief, the target is a lightweight key exchange protocol suitable for IoT
> applications, which:
> >>> b) is not bound to a particular transport, to enable end-to-end
> security in IoT deployments with varying underlying layers; and
> >>> c) can be used to key OSCORE (draft-ietf-core-object-security) that is
> lacking a harmonizing key exchange protocol.
> >>>
> >>> These requirements are motivated by constrained IoT device
> deployments, but the protocol is applicable to other end-to-end security
> settings where the overhead due to security needs to be low. EDHOC
> addresses these requirements and builds on the SIGMA construction for
> Diffie-Hellman key exchanges. EDHOC, like OSCORE, is built on CBOR (RFC
> 7049) and COSE (RFC 8152) and the protocol messages may be transported with
> CoAP (RFC 7252).
> >>>
> >>> 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. There are a few
> implementations of different versions of the draft. The ACE WG has
> expressed interest in this work in several f2f meetings.
> >>>
> >>> Please let us know if some information is missing for secdispatch to
> consider this draft, or how we can help out in the process.
> >>>
> >>> Best regards
> >>> Göran, John, Francesca
> >>>
> >>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 18 Jan 2019 12:15:02 -0500

Sorry, I thought it was a continuation of a private thread that may also benefit from transparency and additional input.

Thank you,
Kathleen 

> On Jan 18, 2019, at 12:12 PM, Richard Barnes <[email-masked]> wrote:
> 
>> On Fri, Jan 18, 2019 at 12:06 PM Kathleen Moriarty <[email-masked]> wrote:

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Jan 2019 11:27:14 -0600

> Let me provide some additional context.  When the chairs and ADs discussed this in BKK, it seemed pretty clear that EDHOC is not within the current charter of ACE — after all, ACE is targeted at au…

ACE's charter is ... messy.  More below.

> Göran: Your email starting this thread seems like an abbreviated summary of the past discussion of this draft.  Since this is a new audience, it would be helpful if you could start from the underly…

There seem to be several interleaved issues at play, here, and I agree that
some clear/consolidated background would be helpful.  I particularly call
out the security proof that has been presented elsewhere, which I think
would be interesting to several readers (but I don't have the link handy).

Some thoughts of my own...

There is clear demand for a lightweight key-exchange protocol for use in
IoT protocols, especially OSCORE.  EDHOC has been around for a while, and
even discussed in ACE with some frequency.  That said, there are several
reasons to prefer asking secdispatch to just calling for adoption in ACE
directly, including but not limited to:

(a) designing secure authenticated key exchange protocols is hard!  It takes
a lot of energy from smart people to design and analyze a protocol to have
confidence that it is secure and fulfils the advertised functions.
Starting from well-known/well-analyzed foundations like SIGMA is a great
start, but hardly a guarantee of success.  Secdispatch gets us some better
visibility, and insight into where work can be done that will have
sufficient expertise (both within and outside the IETF, as well as what has
been done already vs. what remains to be done) to be confident in the
result.

(b) ACE has a pretty complicated charter, that seems to place restrictions
on how it can adopt new protocol work without rechartering.  We find things
in the charter like "existing authentication and authorization protocols
will be evaluated and used where applicable [...].  Some functionality,
however, may not be available in existing protocols, in which case the
solution may involve new protocol work."  This would seem to require a
clear criteria for how to determine whether or not existing technology is
applicable, plus evidence that existing protocols do not meet the bar.  In
particular, "make the key exchange messages as small as possible" is not a
clear criterion, as that would always argue for a new protocol over an
existing one, as we come up with new ways to eke out space.

(c) A clear and substantial difference between key exchange/handshake size
between EDHOC and even minimized DLTS could be compelling enough for
secdispatch to decide that the work is usable, and find an appropriate
home, independently of the question of rechartering ACE and meeting the
additional barrier described in the previous point.

Jim and several others have done some good work looking into tabulating
message overheads in various scenarios (e.g.,
https://www.diva-portal.org/smash/get/diva2:1156483/FULLTEXT01.pdf,
https://jimsch.github.io/randomDrafts/draft-schaad-ace-tls-cbor-handshake.html)
that will be helpful as we consider this topic.

In addition to just comparing the byte count for handshake/key exhchange
messages in various methods, it would probably also be good to think about
things in terms of the constraints in the current ACE charter.  That is,
someone could (1) pick a (class of) device(s), (2) show that it has wide
deployment/potential thereof, (3) give hard numbers about what it's (not)
capable of, and (4) show that DTLS falls on the wrong side of that cutoff,
using the handshake numbers we already have.  In particular, I don't
remember seeing anything touching on (3), previously.  An analysis like
this would not only give some context for interpreting the gap between
EDHOC and DLTS, but could also be compelling in support of the need for the
more lightweight solution.

> If it would be helpful to keep this moving, we could certainly arrange a virtual

That seems likely to be useful, though I suppose we should wait to see more
indication that people would show up and have a productive discussion.

-Ben

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 22 Jan 2019 23:03:12 +0000

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Benjamin Kaduk
> Sent: Friday, January 18, 2019 12:27 PM
> To: Richard Barnes <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Ace] [Secdispatch] EDHOC
> 

IMO, the common thread between both of these practical suggestions is that the complexity of the topic can't entirely fit into the time that would be allotted during secdispatch during the IETF 104 meeting.  Let's start this conversation on list now.

Roman

---

From: Richard Barnes <[email-masked]>
Date: Wed, 23 Jan 2019 11:31:34 -0500

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?

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.

--Richard

On Tue, Jan 22, 2019 at 6:03 PM Roman Danyliw <[email-masked]> wrote:

> IMO, the common thread between both of these practical suggestions is that
> the complexity of the topic can't entirely fit into the time that would be
> allotted during secdispatch during the IETF 104 meeting.  Let's start this
> conversation on list now.
>
> Roman
>

---

From: Göran Selander <[email-masked]>
Date: Thu, 24 Jan 2019 16:31:28 +0000

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)

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.

--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.

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.

Göran

---

From: Göran Selander <[email-masked]>
Date: Thu, 24 Jan 2019 18:28:12 +0000

Hi Ben,

I replied to some of your comments in my previous mail to the list. Additional comments inline.

On 2019-01-18, 18:27, "Benjamin Kaduk" <[email-masked]> wrote:

    

Referenced in Roman's previous mail to secdispatch. I agree that asserting the formal security properties is key.

    
    
This sounds like an excellent support function. Thanks.

I don't know how important it is to fit into the existing ACE charter but the comparison between EDHOC and TLS/DTLS handshake showed a reduction in message overhead with up to 75%, which can be translated into power consumption. I would say that "power efficient key exchange" is functionality not available in the existing protocols we looked at.

The WG is not crucial, but involvement from the user community is valuable as well as the security expertise. 

As mentioned, message overhead differences translate into measurable quantities. While it may be possible to find an example where there is a clear cut, I think for many scenarios there would be qualitative differences.

Göran

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 24 Jan 2019 14:15:33 -0500

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:

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

Anything to prevent further hold ups on this work would be appreciated.

> 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.
>
>
>
>    (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?
>
>
>
> 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

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

-- 

Best regards,
Kathleen