[Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01)

Brian Campbell <bcampbell@pingidentity.com> Thu, 02 July 2015 17:32 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2701A038A for <cose@ietfa.amsl.com>; Thu, 2 Jul 2015 10:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 92wGPiyktExb for <cose@ietfa.amsl.com>; Thu, 2 Jul 2015 10:32:24 -0700 (PDT)
Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60261A0378 for <cose@ietf.org>; Thu, 2 Jul 2015 10:32:23 -0700 (PDT)
Received: by igcsj18 with SMTP id sj18so167943749igc.1 for <cose@ietf.org>; Thu, 02 Jul 2015 10:32:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=ffwlzgKkj2pBGWHt90sSITrDzaKdwUa3dogiu+0hxOc=; b=TYRCn+SeYcNS+L4IxIsDs+/a/4Plt4gqhF6ZLmt+tP0LHOTRG3C2QgnrQnYIUTs5I0 rQ+3Bz0meOHR251ybwEH/3txM3ejPYWvs124doRFM7SstdILhgW+C9CU6yYHXHnDj1n1 En7lcgyG79tyxhUuZdl/FYX8n+u5gXknnkbiQ9hrAtOeAcriIfCwJ6r+5D8LSzFUJCNB qBhRJeY4lPbgrzQA7XEg+/t0rP9iCaCBeWFyjZw501tULxaWd3E6R7HWdMJl34GEoHxl dsy4R1gd1Z7GxzlikZJ+LALrBgcJcYgj4/uQiZCVU9+Nm7BdaIew834iguMVFoJtatxs Nhqw==
X-Gm-Message-State: ALoCoQktvWJ/v2XrEGGyaxnZgKI7Lwry0upevwwijHIN6U8iw85pX/tUtjQFzC1TBtRcUQ6baWsC
X-Received: by 10.42.255.200 with SMTP id nj8mr13484940icb.18.1435858342841; Thu, 02 Jul 2015 10:32:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.64.209 with HTTP; Thu, 2 Jul 2015 10:31:53 -0700 (PDT)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 02 Jul 2015 11:31:53 -0600
Message-ID: <CA+k3eCQUPxZfWM9XcKaTLN-WOx2cHEi9SAGSRFTtv71iSCUqdQ@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Content-Type: multipart/alternative; boundary="bcaec50fe70b792b730519e7d20a"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cose/aUehU6O7Ui8CXcGxy3TquZOxWH4>
Cc: Mike Jones <Michael.Jones@microsoft.com>, cose@ietf.org
Subject: [Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01)
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jul 2015 17:32:25 -0000

What value does key management on the MAC authentication key really
provide? I'm struggling to see it. What I do see is that it will make
messages larger and add complexity. And it seems very likely to be a source
of confusion that results in security problems around when integrity only
is provided vs. integrity and sender authentication. The latter being what
most will expect a MAC provides while the former isn't very useful but
potentially very problematic.

FWIW, I asked same(ish) question on the JOSE list
<http://www.ietf.org/mail-archive/web/jose/current/msg05156.html> yesterday
in regard to an individual draft about key managed MAC keys in JOSE.





On Sat, Jun 27, 2015 at 9:25 AM, Jim Schaad <ietf@augustcellars.com> wrote:





*From:* Cose [mailto:cose-bounces@ietf.org] *On Behalf Of *Mike Jones
*Sent:* Saturday, June 27, 2015 2:07 AM
*To:* cose@ietf.org
*Subject:* [Cose] Review of draft-schaad-cose-msg-01





[JLS] This was discussed on the mailing list.  There are a number of
trade-offs that were discussed.  Please review that discussion and see if
you have something new to add.  Please remember that we are looking at both
the message size and the code size as criteria when making decisions.



*2.  HMACs should be optimized for the no-key-management case.*



Particularly for constrained devices, it is unlikely that applications will
want to pay the performance penalty of generating and encrypting a key
management key to perform a MAC operation.  Heck, they may not have
credible random number generation in the first place!  And they are
likewise unlikely to want to pay the message size penalty of carrying the
encrypted key.



I’m fine with the optional ability to have key management for MACs, but the
default should be that no key management information is present in the
representation.  The only algorithm represented by default should be the
MAC algorithm – not even “dir” (direct).  I suspect that this can be
cleanly done by omitting the key management layer entirely when it’s not
used, rather than explicitly using “dir” (direct).



[JLS] See above.