Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption
"Jim Schaad" <ietf@augustcellars.com> Mon, 13 February 2012 00:51 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF4421F86B0 for <jose@ietfa.amsl.com>; Sun, 12 Feb 2012 16:51:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.381
X-Spam-Level:
X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAY5KvwM8hbl for <jose@ietfa.amsl.com>; Sun, 12 Feb 2012 16:51:33 -0800 (PST)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id D6E2221F86AA for <jose@ietf.org>; Sun, 12 Feb 2012 16:51:33 -0800 (PST)
Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id BC6EA38EA6; Sun, 12 Feb 2012 16:51:32 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: 'John Bradley' <ve7jtb@ve7jtb.com>
References: <9509AB72-10CC-4BA6-A61C-AD9C4AC7944A@cisco.com> <B26C1EF377CB694EAB6BDDC8E624B6E73A8BEDC2@SN2PRD0304MB235.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B16804296739435F7113A8@TK5EX14MBXC285.redmond.corp.microsoft.com> <109CDA9B-7427-4FB5-ADFD-4A72E82E4CAA@cisco.com> <045101cca4c3$87a77b60$96f67220$@augustcellars.com> <32DB7054-1E9F-4BFB-80EC-D5F863C1BB03@ve7jtb.com> <01c401cce9df$1d6db690$584923b0$@augustcellars.com> <2C03AE7C-C9E0-4373-AC95-B265C2F16646@ve7jtb.com> <01cd01cce9e4$9961f1d0$cc25d570$@augustcellars.com> <E37C290E-40DE-4258-A4EB-8254968CC7AD@ve7jtb.com>
In-Reply-To: <E37C290E-40DE-4258-A4EB-8254968CC7AD@ve7jtb.com>
Date: Sun, 12 Feb 2012 16:50:47 -0800
Message-ID: <01e101cce9e9$87236f80$956a4e80$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-index: AQIfXWiGz+BYDGrCkc9B4MZ2d8XmRgGqxNXOAcOgPqsBrEMyFgIUxGhfAb7pkuYCUqYwMgGl5Y1wAg9WY+cCpC1lXZUIREBQ
Cc: 'Mike Jones' <Michael.Jones@microsoft.com>, jose@ietf.org
Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2012 00:51:35 -0000
In this case there was, but normally there is not. The KDF function from ECDH-ES uses SHA-256 as it's primitive. Since the system that I was looking at had no hash functions that did not work in that context. Jim > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Sunday, February 12, 2012 4:26 PM > To: Jim Schaad > Cc: 'Mike Jones'; jose@ietf.org > Subject: Re: [jose] comments on draft-jones-json-web-signature and draft- > jones-json-web-encryption > > I can see adding ECDH-SS for both signing and encryption. It gets you both at > the same time sort of. > > Is there a problem with reusing the KDF from ECDH-ES? > > I think I see what you are after now. > > John B. > On 2012-02-12, at 9:15 PM, Jim Schaad wrote: > > > > > > >> -----Original Message----- > >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] > >> Sent: Sunday, February 12, 2012 4:05 PM > >> To: Jim Schaad > >> Cc: 'Mike Jones'; jose@ietf.org > >> Subject: Re: [jose] comments on draft-jones-json-web-signature and > draft- > >> jones-json-web-encryption > >> > >> > >> On 2012-02-12, at 8:36 PM, Jim Schaad wrote: > >> > >>> > >>> > >>>> -----Original Message----- > >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] > >>>> Sent: Sunday, February 12, 2012 1:41 PM > >>>> To: Jim Schaad > >>>> Cc: 'David McGrew'; 'Mike Jones'; jose@ietf.org > >>>> Subject: Re: [jose] comments on draft-jones-json-web-signature and > >> draft- > >>>> jones-json-web-encryption > >>>> > >>>> Jim, > >>>> > >>>> I may be missing something. > >>>> > >>>> The scenario below is using RFC6278 and pre shared EC keys to crate a > >>> master > >>>> symmetric key to wrap a per message symmetric key used for > generating > >> a > >>>> HMAC, or to use the master symmetric key to wrap a MAC of the > >> message? > >>> > >>> It is using static-ephemeral ECDH (or ECDH-ES) to generate a symmetric > > key > >>> which uses A128KW to wrap a symmetric key which is used to MAC the > >> message. > >> > >> Ah OK you had static static that confused me. We do have ECDSA-ES for > >> encryption, but hadn't thought about it for signing, because it is more > >> integrity, without knowing the identity of the originator. > > > > Yeah - I forgot - it depends on if you want to know who sent it. If you > > want to know who sent it then you need to use static-static. But that is > > completely orthogonal to the rest of the argument. > > > >> > >>> > >>>> > >>>> For EC we only included ECDSA. > >>>> > >>>> The main difference is that with EC-DH-SS only the intended recipient > > can > >>>> verify the message. Slightly different from the ECDSA case. > >>> > >>> But not any different from the case of using a pre-shared secret key and > > a > >>> MAC algorithm. This is the current MUST implement. ECDSA is only a > >> SHOULD > >>> implement. > >> > >> I don't know that we are going to get more agreement on ECDH-ES being > a > >> MUST than ECDSA. > > > > I am not saying that it needs to be a MUST - but the current structure does > > not support it in any fashion. > > > >> > >>> > >>>> > >>>> Is the reason for this performance in a embedded environment? > >>> > >>> In the case I outlined below, yes this is an embedded system. The goal > >> was, > >>> in part, to use the fewest possible cryptographic primitives necessary. > >>> Since encryption was a requirement, there was already AES and EC > >>> shared-secret computation. Using an AES based KDF meant that there > are > >> no > >>> hash functions. Adding integrity protection as well without adding new > >>> primitives was desired. It could use EC + the AES KDF to get a key and > >>> AES-CBC (or AES-GMAC) to compute a MAC by adding only modes. > >> > >> In your original post I missed that the body was encrypted, I thought you > >> were only encrypting the key. > > > > In this case I am not encrypting the body. I am only doing an > > authentication operation. What I am looking at is the number of primitives > > that are required for the sender to be able to do both operations. > > > >> > >> Generating a unauthenticated integrity check. > >> > >> If we are talking about Encryption then ECDH-ES with AES-GWC in the > >> existing spec works. > >> We do need to add the MAC integrity check to support CBC. > >> > >> Again in ECDH-ES only the recipient is authenticated. > >> > >>> > >>>> > >>>> I think there is a general question about key wrapping vs using the > > pre- > >>>> shared or key agreement value directly. > >>>> The current specs lean towards using the values directly rather than > > for > >>> key > >>>> wrapping. > >>>> > >>>> I tend to prefer key wrapping for security, but that depends on people > >>>> actually rotating keys, and it makes the minimum message size larger. > >>> > >>> Actually it is the other way around. Not using key wrapping is more > >>> dependent on people actually rotating keys. If one uses a key > agreement > >> or > >>> key transport to carry the key, then a fresh key is being used for the > > MAC > >>> every time and there is no problems with either forward security or > >>> gathering a large number of messages with the same MAC value and > being > >> able > >>> to do things based on that. So you most likely trading off message size > > for > >>> security depending on the source of the key you are using for the MAC > >>> operation. For example if it came from the TLS session then the answer > >>> would be different. > >> > >> My confidence in people using a fresh key for the MAC each time in > >> wrapping is less than yours. > >> I admit encouraging them to do the right thing is probably the best, > > rather > >> than optimizing for there potential mistakes. > >> > > > > There are a lot of things people can do that is bad. That does not mean we > > should discourage those that want to do it correctly. > > > >> > >>> > >>>> > >>>> Is key agreement for integrity (signing) common? > >>> > >>> How common is it to use MACs? In those cases how many people are > >>> complaining because the shared keys never get rolled over? No it is not > >>> common, what is common is to have no security at all. The next is to > > have > >>> very long term shared keys for doing MACs. > >>> > >>> One could possibly argue that the entire project is a waste of time > > since > >>> all of these items are sent over a TLS session (or should be) and > > therefore > >>> the integrity of the transfer is already protected. This would mean > > that > >>> you are making for bigger messages by adding a second level of integrity > >>> protection. The question is what is the second level of integrity > >>> protection trying to protect? Is it trying to be long term or short > > term? > >>> Without knowing what the goals are, it is not possible to say that the > >>> answer is actually working correctly. > >>> > >> In general with HMAC type integrity checks people infer the identity of > > the > >> originator through the possession of the long term secret. > >> > >> The scenario you present seems to not care about the identity of the > >> originator. > > > > See above note - It actually does use a static-static. But as I can easily > > add to that to the list of "private" algorithms this is not a stumbling > > block. Note that if you look at the above I needed to add a new ECDH > > algorithm in any event since I am not using the standard KDF function. > > > > Jim > > > >> > >> Sorry if the questions are simple. > >> I am just trying to understand the use case. > >> > >> John B. > >> > >>>> > >>>> John B. > >>>> On 2011-11-16, at 9:54 PM, Jim Schaad wrote: > >>>> > >>>>> Mike, > >>>>> > >>>>> I think that while the structures for JWS might need to undergo some > >>>> changes that will mean that while the MAC and Digital Signature > >>> structures. > >>>> As I mentioned at the F2F meeting, I know of someone is doing some > >> small > >>>> device work where they are sending messages from the devices to > more > >>>> central locations. In this case there is not a pre-existing shared > > secret > >>>> generally between the two entities and they are not using TLS so they > >>> could > >>>> not derive one from the session key. Mapping what they do into the > >>> current > >>>> JWS work would require some changes. Specifically > >>>>> > >>>>> Header Object > >>>>> - contains a MAC algorithm to be used - generally AES-GMAC > >>>>> - contains a key wrapping algorithm - generally AES key wrap > >>>>> - contains a key agreement algorithm - generally EC-DH > >>>>> Key Exchange Value - the CEK wrapped by the KEK where the KEK > came > >>>> from the static-static EC-DH algorithm > >>>>> Body > >>>>> MAC value > >>>>> > >>>>> In this case we have four not three items that need to be placed in > > the > >>>> sequence of items to be sent between the originator and the verifier. > > I > >>>> would still compute the MAC value in much the same way, only I would > >>>> compute the MAC over the first three elements instead of the two > >>>> elements. > >>>>> > >>>>> This is the sort of thing that is used in a more store and forward > >>>> environment or one where the answer is going to be pre-computed or > >>>> where it needs to last longer than just the current session (i.e. later > >>>> validation). > >>>>> > >>>>> The same type of thing can be used for a long term shared KEK value > on > >>>> both the sender and recipient, where a unique CEK is generated for > each > >>>> message and wrapped. David would be a better person than I am to > >> address > >>>> the question of security. -"Do you have more security by doing an > >>> indirection > >>>> and have a fresh key for doing the MAC on each operation rather than > >> using > >>>> the long term key for doing the MAC." > >>>>> > >>>>> If we did the above change, then I would say that the "Key Exchange > >>>> Value" would become and empty string if you have a key derivied from > >> the > >>>> TLS session that you are using - but this would still lead to having > > four > >>> not > >>>> three elements in the MAC case. > >>>>> > >>>>> Jim > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> jose mailing list > >>>>> jose@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/jose > >>> > >>> > > > >
- [jose] comments on draft-jones-json-web-signature… David McGrew
- Re: [jose] comments on draft-jones-json-web-signa… Anthony Nadalin
- Re: [jose] comments on draft-jones-json-web-signa… Mike Jones
- Re: [jose] comments on draft-jones-json-web-signa… Nat Sakimura
- Re: [jose] comments on draft-jones-json-web-signa… David McGrew
- Re: [jose] comments on draft-jones-json-web-signa… Nat Sakimura
- Re: [jose] comments on draft-jones-json-web-signa… John Bradley
- Re: [jose] comments on draft-jones-json-web-signa… Jeremy Laurenson (jlaurens)
- Re: [jose] comments on draft-jones-json-web-signa… Phillip Hallam-Baker
- Re: [jose] comments on draft-jones-json-web-signa… Jim Schaad
- Re: [jose] comments on draft-jones-json-web-signa… Mike Jones
- Re: [jose] comments on draft-jones-json-web-signa… Leif Johansson
- Re: [jose] comments on draft-jones-json-web-signa… Matthew Green
- Re: [jose] comments on draft-jones-json-web-signa… John Bradley
- Re: [jose] comments on draft-jones-json-web-signa… John Bradley
- Re: [jose] comments on draft-jones-json-web-signa… Jim Schaad
- Re: [jose] comments on draft-jones-json-web-signa… John Bradley
- Re: [jose] comments on draft-jones-json-web-signa… Jim Schaad
- Re: [jose] comments on draft-jones-json-web-signa… John Bradley
- Re: [jose] comments on draft-jones-json-web-signa… Jim Schaad
- Re: [jose] comments on draft-jones-json-web-signa… Matthew Green