Subject: Re: [Cfrg] When TLS is an overkill...

From: John Mattsson <[email-masked]>
Date: Mon, 4 Mar 2019 07:41:08 +0000

Hi Max,
As you say, EDHOC was not designed to be a general protocol for everything, it was designed to be a very lightweight implementation of the SIGMA protocol to provide keys for OSCORE. That being the case, the protocol should illustrate how a minimal but still practical implementation of SIGMA-I can look like, I hope you find it useful. EDHOC  relies on COSE for all cryptographical parts and will support what COSE standardizes. While RFC 8152 did not support certificates, Jim Schaad is currently working on standardizing support for certificates in COSE, and this will work with EDHOC as well.
https://tools.ietf.org/html/draft-ietf-cose-x509
Cheers,
John
From: Cfrg <[email-masked]> on behalf of "Dr. Pala" <[email-masked]>
Organization: OpenCA Labs
Date: Monday, 25 February 2019 at 17:38
To: "Stanislav V. Smyshlyaev" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Cfrg] When TLS is an overkill...

Hi Stanislav,

I have not read it yet - from the abstract it seems it provides the solution for CBOR/COSE for ECDHE. It is definitely relevant - thanks for the pointer. From what I see, it seems that this is another example of the need for having such BCP (?) that can be implemented in different environments and can use different encodings (e.g., JSON, ASN.1, Binary, XML, etc.)

The specific I-D seems to be a bit too restrictive for a generic protocol - i.e., does not supports certificates, only intended for CBOR/COSE, and does only one algorithm for key exchange: I am thinking more in the direction of an "algorithm-independent" approach that would not require updating when new algorithms for key-exchange, for example, are standardized and deployed (e.g., hash-based signatures) and can support traditional, post-quantum, and future algorithms (as long as no "new paradigm" is introduced). However, besides all these "ecosystem-specific" limitations, the work goes in the same direction as what I am saying here: establish an encryption algorithm and a key by using 3 messages only.

Thanks for the pointer, I will look more closely into that document to see what they include in those messages and why.

Cheers,
Max