IETF Logo Mail Archive

Re: [jose] SPI proposal

Anthony Nadalin <tonynad@microsoft.com> Sat, 09 February 2013 00:43 UTC

Return-Path: <tonynad@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 DB6D621F8C32 for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 16:43:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.534
X-Spam-Level:
X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMRLLwSczdJe for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 16:43:08 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.32]) by ietfa.amsl.com (Postfix) with ESMTP id AD6AA21F8C2C for <jose@ietf.org>; Fri, 8 Feb 2013 16:43:07 -0800 (PST)
Received: from BY2FFO11FD008.protection.gbl (10.1.15.202) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.620.12; Sat, 9 Feb 2013 00:42:58 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD008.mail.protection.outlook.com (10.1.14.159) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Sat, 9 Feb 2013 00:42:58 +0000
Received: from CO9EHSOBE009.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sat, 9 Feb 2013 00:42:56 +0000
Received: from mail85-co9-R.bigfish.com (10.236.132.225) by CO9EHSOBE009.bigfish.com (10.236.130.72) with Microsoft SMTP Server id 14.1.225.23; Sat, 9 Feb 2013 00:42:55 +0000
Received: from mail85-co9 (localhost [127.0.0.1]) by mail85-co9-R.bigfish.com (Postfix) with ESMTP id 8CC8840310 for <jose@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Sat, 9 Feb 2013 00:42:55 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -17
X-BigFish: PS-17(zz98dI9371Ic85fhzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dh18c673hz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh9a9j1155h)
Received-SPF: softfail (mail85-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT001.namprd03.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB044; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en;
Received: from mail85-co9 (localhost.localdomain [127.0.0.1]) by mail85-co9 (MessageSwitch) id 1360370572775233_24862; Sat, 9 Feb 2013 00:42:52 +0000 (UTC)
Received: from CO9EHSMHS003.bigfish.com (unknown [10.236.132.251]) by mail85-co9.bigfish.com (Postfix) with ESMTP id BAD1C3E0045; Sat, 9 Feb 2013 00:42:52 +0000 (UTC)
Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS003.bigfish.com (10.236.130.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 9 Feb 2013 00:42:52 +0000
Received: from BY2PR03MB044.namprd03.prod.outlook.com (10.255.241.148) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.263.1; Sat, 9 Feb 2013 00:42:50 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB044.namprd03.prod.outlook.com (10.255.241.148) with Microsoft SMTP Server (TLS) id 15.0.620.10; Sat, 9 Feb 2013 00:42:48 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.183]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.4]) with mapi id 15.00.0620.005; Sat, 9 Feb 2013 00:42:47 +0000
From: Anthony Nadalin <tonynad@microsoft.com>
To: Brian Campbell <bcampbell@pingidentity.com>, Richard Barnes <rlb@ipv.sx>
Thread-Topic: [jose] SPI proposal
Thread-Index: AQHOBLcZ2BTnadeNlEmbRXkPp/zKN5hueUmAgAI5p2A=
Date: Sat, 09 Feb 2013 00:42:47 +0000
Message-ID: <7cbaa4d142cf45a2bdc5bc29b9c0d579@BY2PR03MB041.namprd03.prod.outlook.com>
References: <CAL02cgSt7w5CrP+DXo7bz_+YsxKsVMoRbZLNWa6EHjnAyScWMg@mail.gmail.com> <CA+k3eCQ_bsTxYq6u5BVe_Xk1ycOhAwWe=ebfAwk+66JavJJQfA@mail.gmail.com>
In-Reply-To: <CA+k3eCQ_bsTxYq6u5BVe_Xk1ycOhAwWe=ebfAwk+66JavJJQfA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [131.107.147.253]
Content-Type: multipart/alternative; boundary="_000_7cbaa4d142cf45a2bdc5bc29b9c0d579BY2PR03MB041namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BY2PR03MB044.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IPV.SX$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%PINGIDENTITY.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(199002)(189002)(377454001)(15202345001)(74502001)(5343635001)(54356001)(47446002)(74662001)(31966008)(46102001)(56776001)(65816001)(56816002)(16236675001)(20776003)(80022001)(53806001)(16676001)(66066001)(63696002)(44976002)(54316002)(47976001)(59766001)(50986001)(6806001)(4396001)(49866001)(5343655001)(51856001)(77982001)(47736001)(76482001)(33646001)(79102001)(512954001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB019; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07521929C1
Cc: "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] SPI proposal
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: Sat, 09 Feb 2013 00:43:09 -0000

I also think that this would be very  cumbersome to support and needs much more thought

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, February 7, 2013 6:43 AM
To: Richard Barnes
Cc: jose@ietf.org
Subject: Re: [jose] SPI proposal

Admittedly I'm not really up on this spi issue or the motivation behind it but a couple questions came to mind when I saw this. How does the receiver protect against unbounded growth of the cache? And index collision? And for distributed environments, it seems supporting this could be very cumbersome.





On Wed, Feb 6, 2013 at 3:11 PM, Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>> wrote:
To move us toward closing Issue #9 [9], here is some proposed text for an SPI [1] field.  To recall, SPI stands for "security parameters index", borrowing a term from IPsec.  The idea is that in cases where the same crypto parameters are being used repeatedly, this would save the parties from having to re-send the same parameters.

The below text is designed for the JWE spec, but could be adapted for JWS (just keep header, ignore part about key/iv).  Similar text is probably needed for the encryption/decryption/signing/verification sections.

Feedback welcome,
--Richard

-----BEGIN-----
Section 4.1.X. "spi" Header Parameter

The "spi" (Security Parameters Index) header parameter contains an opaque byte string that labels a set of security parameters.  This index is designed to enable the use of smaller headers in cases where entities will be re-using the same security parameters for several messages.

Entities supporting the use of the "spi" parameter MUST maintain a table of cached security parameters.  When an entity receives an object whose header contains both "spi" and "alg" values, then it MUST cache the following values from the JWE, indexed by the "spi" value:
-- Contents of the JWE header
-- Encrypted Key
-- Initialization Vector

If an object containing an "spi" parameter but no "alg" parameter, then it MUST NOT contain an Encrypted Key or Initialization Vector.  That is, it will have the form "header.ciphertext.integrity_value".  When a recipient receives such an object, it uses the "spi" value to retrieve cached header, key, and initialization vector and reconstructs a full JWE.  This full JWE can then be further processed according to the normal JWE processing rules.  If the recipient has no cached parameters for the "spi" value, the process MUST fail.
-----END-----


[9] http://tools.ietf.org/wg/jose/trac/ticket/9

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

v2.23.0 | Report a Bug | By Email