IETF Logo Mail Archive

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

Jim Schaad <ietf@augustcellars.com> Tue, 07 April 2020 02:55 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11FE3A13D9 for <core@ietfa.amsl.com>; Mon, 6 Apr 2020 19:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hawOBYvtyKcf for <core@ietfa.amsl.com>; Mon, 6 Apr 2020 19:55:26 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085AC3A13D6 for <core@ietf.org>; Mon, 6 Apr 2020 19:55:25 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 6 Apr 2020 19:55:21 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'John Mattsson' <john.mattsson=40ericsson.com@dmarc.ietf.org>, core@ietf.org
References: <5CD4BE47-4E21-4E00-8BE7-752917CBAF51@ericsson.com>
In-Reply-To: <5CD4BE47-4E21-4E00-8BE7-752917CBAF51@ericsson.com>
Date: Mon, 06 Apr 2020 19:55:20 -0700
Message-ID: <043c01d60c87$fb334d90$f199e8b0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQL8aJ5Y4j4+j1wW67pe+hm3VQlWd6YfmYaw
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/9rLGOQW7fsNEiEPFyIEoBU03Nvs>
Subject: Re: [core] Allowing non-HMAC based KDF in OSCORE
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Apr 2020 02:55:28 -0000


-----Original Message-----
From: core <core-bounces@ietf.org> On Behalf Of John Mattsson
Sent: Friday, April 3, 2020 4:04 AM
To: core@ietf.org
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
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

v2.20.3 | Report a Bug | By Email