Subject: [Ace] edhoc section 4.3.2

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Feb 2017 21:08:23 -0500

It says:
>4.3.2.  message_1 -> V
>
>   Party V processes the received message_1 as follows:
>
>   o  Party V SHALL verify that the nonce has not been received before.
>         If the verification fails, the message MUST be discarded.
>         Otherwise, Party V SHALL store a representation of the nonce
>         for future verifications.

Please clarify "has not been received before". Ever? Or within some
interval?  In IKE, we care about the nonces not being reused during the time
that the node continues to use the same keypair at its end. (In DH,
this means the same y value for g^y). But, you specify a fresh keypair each
time.

Can two nodes U1 and U2 both use the same nonce (by random chance!)
Or must it be unique among all peers?

Storing such nonces is impossible for a constrained node...
Even a non-constained node V won't be able to store many nonces received,
once you count adding indexes to search for the list efficiently.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Göran Selander <[email-masked]>
Date: Fri, 24 Feb 2017 05:48:24 +0000

Hi Michael,

Please see the latest version of EDHOC:
https://ericssonresearch.github.io/EDHOC/

The draft has gone through a number of reviews and is in many ways
rewritten. We will submit a new version next week. Inline:

>this means the same y value for g^y). But, you specify a fresh keypair

Verification of nonces is now optional (e.g. section 4.2.3). Nonces are
not allowed to be reused but it is noted that replay of message_1 cannot
be detected unless unless previous nonces are stored (see security
considerations).

In issue 16 it was requested to allow multiple uses of ephemeral keys and
it was added in the security considerations. I think it makes sense to
mandate the verification of nonce uniqueness during reuse of ephemeral
keys and have reopened issue 16:

https://github.com/EricssonResearch/EDHOC/issues/16

>once you count adding indexes to search for the list efficiently.

Agree.

Göran

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Feb 2017 08:15:01 -0500

N_U, N_V, E_V, Alg_V, Enc(K_VE; ID_V, Sig(V; Mac(K_VM; prot_2)))|
    | <---------------------------------------------------------------+
        |                             message_2                           |
            |
|
    |                                                                 |
        |    N_U, N_V, Enc(K_UE; ID_U, Sig(U; Mac(K_UM; prot_3)))

Why is N_U echoed back to U in message 2?
Why are N_U and N_V included in message 3?

If the nonce acts as a defense against off-path attacks, then at least
N_U does not need to be in message 3.  Including N_U in message 2 defends
an off-path attacker racing V to reply to message_1, which seems unlikely.

---

From: Göran Selander <[email-masked]>
Date: Fri, 24 Feb 2017 14:06:37 +0000

Michael, 

This has already been updated in the latest version on the Github:
https://ericssonresearch.github.io/EDHOC/

As I mentioned we will submit to the IETF a new version next week, pending
some expected review comments.

Göran

On 2017-02-24 14:15, "Michael Richardson" <[email-masked]> wrote:

>        |                             message_2

---

From: John Mattsson <[email-masked]>
Date: Fri, 24 Feb 2017 14:14:00 +0000

N_U serves as a session identifier. That is the reason it is bounced back in message_2.

Both N_U and N_V is not needed in message_3. In the updated version on  Github only a single session identifier is used in message_3

Sent from my Cray-1

> On 24 Feb 2017, at 15:07, Göran Selander <[email-masked]> wrote:
> 
> Michael, 
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Feb 2017 12:03:40 -0500

Göran Selander <[email-masked]> wrote:
    > In issue 16 it was requested to allow multiple uses of ephemeral keys
    > and it was added in the security considerations. I think it makes sense
    > to mandate the verification of nonce uniqueness during reuse of
    > ephemeral keys and have reopened issue 16:

    > https://github.com/EricssonResearch/EDHOC/issues/16

Good, this lets a node trade off storage and compute power.