Re: [Secdispatch] [Ace] EDHOC

[Kathleen Moriarty <[e-mail]>]

Will there be an interim for this topic?

Thank you,
Kathleen

On Thu, Jan 24, 2019 at 2:15 PM Kathleen Moriarty <
[e-mail]> 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 <
> [e-mail]> wrote:
>
>> Hi Richard, Roman, all
>>
>>
>>
>> Thanks for kind welcome and for progressing the discussion. Apologies for
>> a long email.
>>
>>
>>
>> *From: *Richard Barnes <[e-mail]>
>>
>>
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ace
>>
>
>
> --
>
> Best regards,
> Kathleen
>


-- 

Best regards,
Kathleen