Subject: [core] Allowing non-HMAC based KDF in OSCORE

From: John Mattsson <[email-masked]>
Date: Fri, 3 Apr 2020 11:03:54 +0000

Hi,

As pointed out by Jim in the COSE virtual interim yesterday, OSCORE restricts the type of KDF to HMAC-based HKDF algorithms. I do not know (or remember) why the restriction is there.

- There are no security reasons for the limitation (at least not if Master Secret is uniformly random), and it currently hinders OSCORE to be used with the COSE AES based KDFs.
- The restriction is currently a practical problem. 6TiSCH people have stated that using AES and SHA-256 is not a problem at all.
- however, the restriction may be more limiting in the future. COSE is currently discussing adding KMAC. For a node implementign SHAKE128, HMAC is overkill, and KMAC is a simpler and more lightweight alternative. HMAC was specifically design to mitigate the length extension attacks of early hash functions and is not needed for SHA-3. NIST lightweight crypto competition have many primitives that can be used for both AEAD and hashing, they will likely have lightweight KDF modes different from HMAC mode.

I don't think there is any hurry to change this restriction but I think it should be changed at some point. It makes sense for OSCORE to allow any KDF specified in COSE. I would suggest that Group OSCORE (which updates OSCORE) lifts this limitation also for RFC 8613. Another possibility is to write a new draft, but it seems easier to just put it in Group OSCORE.

Cheers,
John

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 6 Apr 2020 18:18:08 +0200

Hello John,

On Fri, Apr 03, 2020 at 11:03:54AM +0000, John Mattsson wrote:
> As pointed out by Jim in the COSE virtual interim yesterday, OSCORE
> restricts the type of KDF to HMAC-based HKDF algorithms. I do not know
> (or remember) why the restriction is there.

from an implementer point of view, it would be much appreciated if an
OSCORE library would only need to ask its backend COSE library things it
can know (eg. whether an algorithm is a KDF algorithm) and not have to
ship additional knowledge about algorithms.

> I don't think there is any hurry to change this restriction but I
> think it should be changed at some point. It makes sense for OSCORE to
> allow any KDF specified in COSE. I would suggest that Group OSCORE
> (which updates OSCORE) lifts this limitation also for RFC 8613.

If we go that route (which sounds viable to me), could we have a "There
are no technical reasons why this could not be extended to (non-group)
OSCORE; updating that specification in a later document is being
considered." in there?

KR
c

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn

---

From: Jim Schaad <[email-masked]>
Date: Mon, 6 Apr 2020 19:55:20 -0700

-----Original Message-----
From: core <[email-masked]> On Behalf Of John Mattsson
Sent: Friday, April 3, 2020 4:04 AM
To: [email-masked]
Subject: [core] Allowing non-HMAC based KDF in OSCORE

 Hi,

As pointed out by Jim in the COSE virtual interim yesterday, OSCORE
restricts the type of KDF to HMAC-based HKDF algorithms. I do not know (or
remember) why the restriction is there.

- There are no security reasons for the limitation (at least not if Master
Secret is uniformly random), and it currently hinders OSCORE to be used with
the COSE AES based KDFs.
- The restriction is currently a practical problem. 6TiSCH people have
stated that using AES and SHA-256 is not a problem at all.
[JLS] I am not sure that I under stand where the immediate practical problem
is.  If SHA-256 is not a problem then HMAC-SHA-256 can be used as the PDF
for HKDF.

- however, the restriction may be more limiting in the future. COSE is
currently discussing adding KMAC. For a node implementign SHAKE128, HMAC is
overkill, and KMAC is a simpler and more lightweight alternative. HMAC was
specifically design to mitigate the length extension attacks of early hash
functions and is not needed for SHA-3. NIST lightweight crypto competition
have many primitives that can be used for both AEAD and hashing, they will
likely have lightweight KDF modes different from HMAC mode.

I don't think there is any hurry to change this restriction but I think it
should be changed at some point. It makes sense for OSCORE to allow any KDF
specified in COSE. I would suggest that Group OSCORE (which updates OSCORE)
lifts this limitation also for RFC 8613. Another possibility is to write a
new draft, but it seems easier to just put it in Group OSCORE.

[JLS] Right - as of today the legal set of values for this should be -10,
-11, -12 and -13.  Instead only the first two are legal because of the
restriction to HMAC as the pdf.

Jim

Cheers,
John

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

---

From: John Mattsson <[email-masked]>
Date: Tue, 7 Apr 2020 04:29:19 +0000

- Jim Schaad wrote:

[JPM] Sorry my fault, I intended to write to write the opposite: "The restriction is currently NOT a practical problem", but Christian seems to think it is inconvenient.

John

---

From: John Mattsson <[email-masked]>
Date: Tue, 7 Apr 2020 04:33:12 +0000

[JPM] I was more thinking that Group OSCORE document already now writes that

    This document updates RFC 8613 as follows:
   
    OLD: The HKDF MUST be one of the HMAC-based HKDF [RFC5869] algorithms
   defined for COSE [RFC8152].

   NEW: The KDF MUST be one of the KDF algorithms defined for COSE [RFC8152]

John

-----Original Message-----
From: Christian Amsüss <[email-masked]>
Date: Monday, 6 April 2020 at 18:18
To: John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [core] Allowing non-HMAC based KDF in OSCORE

    Hello John,

    

    KR
    c

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 7 Apr 2020 09:24:20 +0200

>   NEW: The KDF MUST be one of the KDF algorithms defined for COSE [RFC8152]

(Maybe reference 8152bis-algs here.)

Grüße, Carsten

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 7 Apr 2020 11:12:43 +0200

>    NEW: The KDF MUST be one of the KDF algorithms defined for COSE [RFC8152]

I was probably too hasty reading that; yes, that's even better to me.

Thanks
c