Subject: [COSE] FW: New Version Notification for draft-selander-ace-cose-ecdhe-00.txt

From: Göran Selander <[email-masked]>
Date: Wed, 23 Mar 2016 07:32:06 +0000

Dear COSE and ACE,

We have submitted a draft on ephemeral-ephemeral Diffie-Hellman key
exchange embedded in COSE objects.

Two versions are presented, one authenticated with pre-shared keys, and
one authenticated with static ECDH public keys. The keys used to
authenticate the DH-exchange can be obtained as defined in the ACE
solution. 

In the appendices we indicate how the DH key exchange can be embedded in a
CoAP request-response, and in particular in the same CoAP message exchange
which provides the access token to the resource server in the ACE
solution. We also show how to derive OSCOAP security context from the DH
shared secret.

We would like to discuss the COSE aspects of this draft in the COSE WG
meeting.

Regards
Göran

On 2016-03-21 17:57, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-selander-ace-cose-ecdhe-00.txt
>has been successfully submitted by Goeran Selander and posted to the
>IETF repository.
>
>Name:		draft-selander-ace-cose-ecdhe
>Revision:	00
>Title:		Ephemeral Diffie-Hellman Over COSE (EDHOC)
>Document date:	2016-03-21
>Group:		Individual Submission
>Pages:		19
>URL:            
>https://www.ietf.org/internet-drafts/draft-selander-ace-cose-ecdhe-00.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/
>Htmlized:       
>https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-00
>
>
>Abstract:
>   This document specifies the Diffie-Hellman key exchange with
>   ephemeral keys embedded in messages encoded with the CBOR Encoded
>   Message Syntax.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 23 Mar 2016 20:27:12 +0200

> authenticate the DH-exchange can be obtained as defined in the ACE

Looks like the ECDH-SS variant is vulernable to KCI (e.g attacker
knowing s can authenticate as arbitrary client).

Also, that g^xs is involved makes it highly important that that
invalid-curve attacks are properly defended against (point validation
or ladders with twist-secure curves).

-Ilari

---

From: Göran Selander <[email-masked]>
Date: Wed, 23 Mar 2016 22:59:47 +0000

Hi Ilari,

Thanks for comments. You are right. I tried to use ECDH-SS in an attempt
to get MACs instead of signatures, but as far as I understand all -SS seem
vulnerable to KCI.

The next best would be just signature on one of the messages. Do you or
anyone else have a recommendation instead of me making more embarrassing
attempts?

Thanks
Göran

On 2016-03-23 19:27, "[email-masked] on behalf of Ilari

---

From: Göran Selander <[email-masked]>
Date: Thu, 24 Mar 2016 11:49:58 +0000

Now I’ve lost all illusions of saving in on signatures. We’ll replace the
MACs with signatures together with some other changes and submit a new
version as soon as the submission tool reopens.

Göran

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 27 Mar 2016 19:55:03 +0300

> version as soon as the submission tool reopens.

The off-list message reply bounced, so briefly...

- Message 2 needs a MAC, or there will be identity misbinding attack.
- It must be infeasible to derive MAC key from key exposed to the
  protocol running on top, or vice versa, or generic security breaks.
- KEA+... While searching what it is I ran into mention about "KEA+
  patents" (with no further info).
- If attacker learns the dlog of client's DH key used in key exchange,
  they can impersonate the client (this seems fundamental to all two-
  step protocols).

There might be other attacks too...

-Ilari