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

"Jim Schaad" <ietf@augustcellars.com> Tue, 07 July 2015 23:25 UTC

Return-Path: <ietf@augustcellars.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 CCE9E1B2A2F for <cose@ietfa.amsl.com>; Tue, 7 Jul 2015 16:25:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 91x4aMD4CZkn for <cose@ietfa.amsl.com>; Tue, 7 Jul 2015 16:25:23 -0700 (PDT)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2183C1B2A13 for <cose@ietf.org>; Tue, 7 Jul 2015 16:25:23 -0700 (PDT)
Received: from hebrews (174-21-18-91.tukw.qwest.net [174.21.18.91]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 6F42238EE6; Tue, 7 Jul 2015 16:25:22 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Mike Jones' <Michael.Jones@microsoft.com>
References: <CA+k3eCQUPxZfWM9XcKaTLN-WOx2cHEi9SAGSRFTtv71iSCUqdQ@mail.gmail.com> <559576A9.9090002@gmx.net> <BY2PR03MB442C02F758E34B29BBD0CEAF5970@BY2PR03MB442.namprd03.prod.outlook.com>
In-Reply-To: <BY2PR03MB442C02F758E34B29BBD0CEAF5970@BY2PR03MB442.namprd03.prod.outlook.com>
Date: Tue, 07 Jul 2015 16:25:39 -0700
Message-ID: <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQGMo9E7lz5K1VbQVek9kTd0WZ5EKwIS9FwIAQ3LxPSeP8TTEA==
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/cose/ouOIdAOe2P-W8BjGLJ7BNvvRr10>
Cc: cose@ietf.org
Subject: Re: [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: Tue, 07 Jul 2015 23:25:25 -0000


> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Thursday, July 02, 2015 10:53 AM
> To: Hannes Tschofenig; Brian Campbell; Jim Schaad
> Cc: cose@ietf.org
> Subject: RE: [Cose] Key management for MACs (was Re: Review of draft-
> schaad-cose-msg-01)
> 
> If MACs without key management were insecure, I'm sure that JWS [RFC
> 7515] wouldn't have survived the SecDir review or the IESG review since it
> has no key management for MACs, but it did.

[JLS] There was no assumption that there was no key lifetime management for
the case of JWS or JWE.  The assumption was that the key management was
being down outside of these documents.  I am sure (or at least strongly
hope) that nobody is suggesting that a single key was going to be negotiated
between the sender and the receiver of a message and it would never be
modified in the future.  

> 
> The question is what *additional* value key management adds in the MAC
> case.

http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/multi-
forge-01.pdf

provides a method to looking at how to attack a key.  This would be done by
looking at the recipient of the message as an oracle to see how it responds
to messages.  The more one uses the same key the more data there is to work
with to attack keys.  From this point of view, encryption can be better
because traffic analysis might be all you get from re-using a key.

Even doing something as simple as running the shared secret through a KDF
(with perhaps a sequence number or time marker in the context) will make the
system more secure as the same key is no longer being used to MAC every
message.

> 
> (I completely understand the value of key management in the encryption
> case.  If you're using a deterministic content encryption algorithm and
> you're encrypting the same plaintext with the same key without key
> management, the ciphertext values will match, allowing attackers to
> correlate messages.  Using a randomly generated content encryption key
> means that encryptions of the same plaintext result in different
ciphertext
> values - preventing this correlation.  But the payload in a MAC is not a
> secret, so there's no equivalent benefit in the MAC case.)
> 
> 				-- Mike
> 
> -----Original Message-----
> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
> Sent: Thursday, July 02, 2015 10:37 AM
> To: Brian Campbell; Jim Schaad
> Cc: Mike Jones; cose@ietf.org
> Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-
> schaad-cose-msg-01)
> 
> 
> 
> > 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.
> 
> It would be good to know what devices you have in mind in this discussion.
> 
> I personally don't think we should target devices that cannot even do key
> management for symmetric cryptography. I would even argue that we
> should aim for devices that support a random number generator and are
> also able to do public key crypto.
> 
> We are not doing ourselves a flavor if we place artificial constraints on
our
> protocols that make them pretty insecure in practice. We already have
> enough insecure IoT devices in the market.
> 
> Here is the slide deck I presented in the LWIG group at the last IETF
> meeting; it explains the performance of state-of-the-art crypto on common
> Cortex M class MCUs.
> https://www.ietf.org/proceedings/92/slides/slides-92-lwig-3.pdf
> 
> Ciao
> Hannes