IETF Logo Mail Archive

Re: [jose] JOSE dependence on "Key Guessing"

Mike Jones <Michael.Jones@microsoft.com> Wed, 07 February 2018 06:22 UTC

Return-Path: <Michael.Jones@microsoft.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 006B81204DA for <jose@ietfa.amsl.com>; Tue, 6 Feb 2018 22:22:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 AQOI4E70f2kQ for <jose@ietfa.amsl.com>; Tue, 6 Feb 2018 22:22:38 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0125.outbound.protection.outlook.com [104.47.33.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE9412DA15 for <jose@ietf.org>; Tue, 6 Feb 2018 22:22:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zEDQctWv9FBa7jJRSnwSRm5FCmNZZPxaVvWrR6IA/eY=; b=JiXBgFPjvsJXx0Ytks3ZE+QgJy+PJ97oNbpui/LEzTNOd9bo83nMRsOkcmAnRM91YDk9oxdmFyjUwdnVM9y77wl++xNTvvS9jOLPuC8eA1ipWJQPWcVGQQOdEwo2ufFO9Hci8PRoEu2c7LRCXYc74R1mYJO1DPf021ZzzNG2D+Q=
Received: from SN6PR2101MB0943.namprd21.prod.outlook.com (52.132.114.20) by SN6PR2101MB1056.namprd21.prod.outlook.com (52.132.115.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.1; Wed, 7 Feb 2018 06:22:36 +0000
Received: from SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::7068:47f5:3e1c:ce6a]) by SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::7068:47f5:3e1c:ce6a%6]) with mapi id 15.20.0506.007; Wed, 7 Feb 2018 06:22:36 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, "jose@ietf.org" <jose@ietf.org>
Thread-Topic: [jose] JOSE dependence on "Key Guessing"
Thread-Index: AQHTn9lomkEOFLfo+0GYeDB3m0ydk6OYd13Q
Date: Wed, 07 Feb 2018 06:22:35 +0000
Message-ID: <SN6PR2101MB09437284FC84E3154BC8C64EF5FC0@SN6PR2101MB0943.namprd21.prod.outlook.com>
References: <6b3f854d-f370-8f94-12ca-0f8ae0051362@gmail.com>
In-Reply-To: <6b3f854d-f370-8f94-12ca-0f8ae0051362@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [50.47.88.236]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN6PR2101MB1056; 7:t7HmJSocIhryvpMmd1k2LBwAFAqBc3NXGglIzfLnvH9IbQoxSUM89Ut62WOuanXG60rioOaxaTzW5zbcwvSij+MRpkZNf0qAFhw64zrnMSdAv0/o3awvRplRytkh4rqRpLgAv2H7qdBiF1FWIHC/Wdz2/6SilwuS7t+HSItsJM/y2dCT9U6lKY6jqXs39EFUF5YQypo/PTVctqumtxKZjQUdwdc6rcKYlXa0ZdesYx4bWKuHGMpXtCp03XgaA5bx
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 885dd513-580c-466b-4c4b-08d56df32e1a
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:SN6PR2101MB1056;
x-ms-traffictypediagnostic: SN6PR2101MB1056:
x-microsoft-antispam-prvs: <SN6PR2101MB1056E670613AA449735B47E3F5FC0@SN6PR2101MB1056.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(3002001)(3231101)(2400082)(944501161)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:SN6PR2101MB1056; BCL:0; PCL:0; RULEID:; SRVR:SN6PR2101MB1056;
x-forefront-prvs: 0576145E86
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(346002)(376002)(39380400002)(39860400002)(189003)(199004)(13464003)(305945005)(2950100002)(6116002)(186003)(6346003)(9686003)(6306002)(3846002)(105586002)(7736002)(66066001)(10290500003)(316002)(39060400002)(5660300001)(7696005)(966005)(14454004)(22452003)(102836004)(86362001)(25786009)(26005)(76176011)(53546011)(6506007)(59450400001)(110136005)(53376002)(3660700001)(86612001)(8990500004)(10090500001)(478600001)(68736007)(74316002)(8676002)(81166006)(2501003)(2906002)(106356001)(8936002)(81156014)(229853002)(97736004)(53936002)(3280700002)(2900100001)(33656002)(72206003)(5250100002)(99286004)(6246003)(6436002)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR2101MB1056; H:SN6PR2101MB0943.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-microsoft-antispam-message-info: 5lQj4VJvzlAVggH9ALXbvA99jXD+y5vLcRb1DwtxWudioGV8sduZjJXrP8aRgAD9Q/asGt+t6a9PdeQGVjhBtA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 885dd513-580c-466b-4c4b-08d56df32e1a
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2018 06:22:35.9458 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR2101MB1056
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/Gf5RzeQ8aCmhfWfY5nEs1sa2op4>
Subject: Re: [jose] JOSE dependence on "Key Guessing"
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 07 Feb 2018 06:22:40 -0000

Anders, you misunderstand the feature and its purpose.  The ability to reference a set of keys is essential to performing key roll-over - a critical security function.  The "kid" (key ID) value is typically used to indicate which member of the key set was employed.  There is no "key guessing".

For an example of how JWK sets are used for key roll-over in a production system, see http://openid.net/specs/openid-connect-core-1_0.html#Signing.

				-- Mike

-----Original Message-----
From: jose <jose-bounces@ietf.org> On Behalf Of Anders Rundgren
Sent: Tuesday, February 6, 2018 10:03 PM
To: jose@ietf.org
Subject: [jose] JOSE dependence on "Key Guessing"

Dear list,

Believe or not but there is a new multi-party IETF effort in the workings for dealing with "clear text" versions of JWS and JWE.  Our BOF request was though turned down due to lack of published drafts and "customers" so issues will have to go through the mailing list only.

The goal is reusing as much as possible of the existing specifications, essentially limiting the work to repackaging.

However, it turned out that I wasn't fully up-to-date on the JOSE concept "Key Guessing":
https://tools.ietf.org/html/rfc7515#appendix-D

As far I can tell they only way you would ever need to do "Key Guessing" as described in appendix-D is if you have a scheme where the sender doesn't inform the receiver which key it actually used which sounds like a poor idea as well as highly unlikely to be used anywhere in practice.

Therefore I didn't bother too much with that until I had implemented support for JKU where the sender supplies a URL to a set of keys for the receiver to try out.  That is, "Key Guessing" is not only a possibility, it is an intrinsic part of the JOSE specifications.

So the question simply boils down to: Should derived standards-to-be, inherit obvious design flaws as well? IMO, they should not.  JKU could be redefined to point to a single JWK, removing the need for "Key Guessing" altogether.  Yes, there are "workarounds" like requiring additional key identification properties...

thanx,
Anders

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

v2.23.0 | Report a Bug | By Email