Subject: [Ace] HKDF useage in ace-cose-ecdhe-05

From: Dan Harkins <[email-masked]>
Date: Wed, 29 Mar 2017 14:55:21 -0700

Hello,

   I want to expand on my comments I made at the mic on Monday regarding
key derivation with symmetric key authentication in draft-selander-ace-
cose-ecdhe-05. When doing authentication with symmetric keys message 1 is
encrypted using K_1 and K_1 is generated by passing (as far as I can tell,
and I did admit at the mic that it's a little fuzzy) the PSK as salt and
an empty key to HKDF. This poses some problems I think.

   - The only source of entropy in K_1 is the PSK and this makes the 
protocol
     susceptible to a passive dictionary attack[1] that would, 
otherwise, not
     be possible.

   - It seems somewhat unhygienic, from a crypto point of view, to pass
     a NULL key to a key derivation function.

   - Use of the PSK in messages 2 and 3 authenticate the particular key
     used in the AEAD and decryption/verification provides authentication of
     the sender to the receiver. But for message 1 is different. There is
     no benefit to the key exchange provided by encryption of message 1.

   The sole benefit of encrypting in message 1 seems to be that EXT_1 gets
encrypted. But EXT_1 in the asymmetric case is not encrypted so there
doesn't really seem there can be much that needs protection; seems like
this is more of an opportunistic thing. That being the case, there is
little upside and considerable downside to generating K_1 and encrypting
a portion of message 1. I recommend that being removed from the draft.

   regards,

   Dan.

[1] a dictionary attack is defined as one where the attacker gains an
advantage from computation as opposed to interaction. The size of the
dictionary (e.g. all numbers between 0 and 2^256) only affects the
probability of success of the attack not whether it is a dictionary
attack or not.

---

From: Göran Selander <[email-masked]>
Date: Thu, 30 Mar 2017 06:30:54 +0000

Hello Dan,

Thanks for commenting.

The encryption of K_1 in the symmetric case is an open issue, we should
have mentioned that in the meeting. Jim Schaad has also provided arguments
to remove it.

Your expression “opportunistic” is a good characterisation. We included
encryption and integrity protection of message_1 in the symmetric version
mainly because we can, in contrast to in the asymmetric version. But as
you point out, if we keep encryption of message_1 then we should derive
K_1 in a different way, and then the key derivation in the asymmetric and
symmetric versions of the protocol would probably not be the same, which
was another design objective.

I haven’t talked with my co-authors yet, but we will either omit
encryption of message_1 in the symmetric case or change the derivation of
K_1.

Regards,
Göran

On 2017-03-29 23:55, "Ace on behalf of Dan Harkins" <[email-masked]
on behalf of [email-masked]> wrote:

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