Re: [jose] Reducing the size of JWS payloads

Mike Jones <Michael.Jones@microsoft.com> Wed, 19 December 2012 22:06 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 EE3E021F8577 for <jose@ietfa.amsl.com>; Wed, 19 Dec 2012 14:06:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.783
X-Spam-Level:
X-Spam-Status: No, score=-2.783 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001]
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 D84-dCClybZ1 for <jose@ietfa.amsl.com>; Wed, 19 Dec 2012 14:06:59 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id BA3EB21F854F for <jose@ietf.org>; Wed, 19 Dec 2012 14:06:58 -0800 (PST)
Received: from BL2FFO11FD015.protection.gbl (10.173.161.204) by BL2FFO11HUB036.protection.gbl (10.173.161.116) with Microsoft SMTP Server (TLS) id 15.0.578.12; Wed, 19 Dec 2012 22:06:55 +0000
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Wed, 19 Dec 2012 22:06:55 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Wed, 19 Dec 2012 22:06:08 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Dick Hardt <dick.hardt@gmail.com>, Richard Barnes <rbarnes@bbn.com>
Thread-Topic: [jose] Reducing the size of JWS payloads
Thread-Index: Ac3dkDn1ScBaTFOCSwGyAjfBe1wGHgAAqR2AACLdd6AAAKdfAAAAs7UAAAMgpIAAAHm+AAAAiHNQ
Date: Wed, 19 Dec 2012 22:06:08 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366977921@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com> <A96543D2-9380-4191-89AD-6A896B461938@gmail.com> <4E1F6AAD24975D4BA5B16804296739436697751F@TK5EX14MBXC283.redmond.corp.microsoft.com> <AAA7B9B4-A80D-4689-92CD-F037CCEC9AAD@gmail.com> <BD6E7311-2776-4736-95E7-7E8E0B1AF1AB@gmail.com> <B1BAC068-A003-41DD-A21C-976AEBDAEA57@bbn.com> <A5DFD321-FC3B-4363-BF15-291C9C90A1CB@gmail.com>
In-Reply-To: <A5DFD321-FC3B-4363-BF15-291C9C90A1CB@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.74]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(52604002)(51704002)(377454001)(24454001)(13464002)(15202345001)(56776001)(47776002)(47446002)(74662001)(5343635001)(53806001)(33656001)(51856001)(55846006)(76482001)(44976002)(56816002)(54356001)(16406001)(46406002)(23726001)(59766001)(550184003)(54316002)(77982001)(49866001)(31966008)(5343655001)(50986001)(4396001)(47976001)(74502001)(50466001)(47736001)(46102001)(503574001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB036; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 070092A9D3
Cc: "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Reducing the size of JWS payloads
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: Wed, 19 Dec 2012 22:07:00 -0000

That's a much bigger structural change.  If what you're trying to do is to avoid the overhead of integrity protecting the content twice, instead, while this may be heretical to some, you could create a JWE with AES CBC and an empty integrity check value ("enc":"A128CBC") and then use that as a JWS payload.  It would mean that we would once again have an encryption algorithm with no integrity check.  That could be accompanied with Security Considerations caveats that this algorithm MAY NOT be used unless the resulting JWE was integrity checked through other means, such as being used as the payload of a JWS with an appropriate signature/MAC algorithm.

The upside of that approach is that you'd have two separate sets of headers for the two different operations without making significant syntax changes to the JWE header format.

				-- Mike

-----Original Message-----
From: Dick Hardt [mailto:dick.hardt@gmail.com] 
Sent: Wednesday, December 19, 2012 1:46 PM
To: Richard Barnes
Cc: Dick Hardt; Mike Jones; jose@ietf.org
Subject: Re: [jose] Reducing the size of JWS payloads

That is why one would be in the 'enc' sub-object, something like this:

{ 
, 'kid': 		// signing key id
, 'alg':		// signing algorithm
, 'enc': 
	{ 'kid':	// encryption key id
	, 'alg':	// encryption algorithm
	}
}


On Dec 19, 2012, at 1:31 PM, Richard Barnes <rbarnes@bbn.com> wrote:

> In which order?  Just having two "kid" values seems ambiguous.
> 
> 
> On Dec 19, 2012, at 3:02 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
> 
>> Um, yeah.
>> 
>> I have the keys backwards.
>> 
>> If I am signing with my private key and encrypting with the recipients public key ... 
>> 
>> On Dec 19, 2012, at 11:42 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
>> 
>>> Hi Mike
>>> 
>>> Either I don't understand your answer or you don't understand what I was saying, so let me elaborate.
>>> 
>>> If I am signing with the recipients public key and encrypting with my private key, I need to have two 'kid' values and possible other cryptography header values.
>>> 
>>> -- Dick
>>> 
>>> On Dec 19, 2012, at 11:36 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>> 
>>>> Hi Dick,
>>>> 
>>>> The way to do that with the current spec is to define a new composite encryption/integrity algorithm that does what you want.  For instance, the "A128CBC+HS256" composite algorithm performs encryption with AES CBC and the integrity check with HMAC SHA-256.  I could imagine an "A128CBC+ES256" algorithm that performs the encryption with AES CBC and the integrity calculation with ECDSA P-256 SHA-256.  The key for that composite algorithm could be the concatenation of a 128-bit CBC key and the ECDSA key.
>>>> 
>>>> For what it's worth, until draft -06, the block encryption algorithm and the integrity algorithm were separately specified (in "enc" and "int") parameters.  The working group made a decision to only support encryption algorithms that provided integrity - hence the use of composite algorithms when using CBC (which doesn't provide integrity itself.  However, you still would have had to define a new "int" algorithm even when they were separate, because the only integrity algorithms specified were HS256, HS384, and HS512.
>>>> 
>>>> 				-- Mike
>>>> 
>>>> -----Original Message-----
>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dick Hardt
>>>> Sent: Tuesday, December 18, 2012 6:45 PM
>>>> To: Mike Jones
>>>> Cc: jose@ietf.org; Dick Hardt
>>>> Subject: Re: [jose] Reducing the size of JWS payloads
>>>> 
>>>> Hi Mike
>>>> 
>>>> Thanks for bringing this up again. 
>>>> 
>>>> An alternative approach I proposed was to have both the encryption and signing information in one header, and to use the signing signature to ensure integrity instead of having a separate encryption integrity check. This would reduce the size of the token by the size of the integrity value +1 bytes, as well as reduce the processing.
>>>> 
>>>> Given that header properties are overloaded now (they have different meanings depending on being a JWE or JWS, we could put the encryption header values into a sub object in the header. Perhaps call that 'enc'.
>>>> 
>>>> -- Dick
>>>> 
>>>> The process below has 
>>>> On Dec 18, 2012, at 6:26 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>> 
>>>>> I've noticed that more than one person has expressed a desire to reduce the size of JWS payloads before signing.  This especially comes up when nested encryption and signing is being performed.  This note contains a quantitative evaluation of some possible methods of reducing JWS payload size and asks for working group input based upon the data.
>>>>> 
>>>>> Dick proposed one method below - have a header parameter to say that the payload is already URL-safe and that base64url encoding is not to be performed.  Another way that people have proposed is to allow the use of the "zip" parameter to compress the JWS payload before base64url encoding.  To get some initial data on how the solutions compare, I tried both methods using the sample JWE value in http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07#appendix-A.2 as the JWS payload.
>>>>> 
>>>>> CURRENT SITUATION:  The JWE is 526 characters in length.  Currently, when used as a JWS payload, base64url encoding it would increase its size to 702 characters - an increase of 33% or 176 characters.
>>>>> 
>>>>> AVOIDING DOUBLE BASE64URL ENCODING:  If we used a header parameter "b64":false to indicate that no additional base64url encoding is to be performed, the payload would be 176 characters smaller than the current situation.  The encoded header size would increase by 16 characters - the number of characters needed to base64url encode this header parameter value and a comma, for a net decrease in size of 160 characters.  (Yes, parsing the three pieces would be slightly more difficult.)
>>>>> 
>>>>> APPLYING DEFLATE TO THE PAYLOAD:  Believe it or not, using DEFLATE on this input results in a LARGER output - 536 bytes or a net increase of 10 bytes.  If you think about it, this isn't too surprising, as the encrypted data should contain no usable predictability/redundancy.  Base64url encoding these 536 bytes results in a 715 character payload - an increase of 189 characters or 36%.  Plus, adding "zip":"DEF" to the header adds 16 characters, for a total increase of 29 characters over the current situation.  Clearly a suboptimal choice!
>>>>> 
>>>>> CONCLUSION:  Clearly, if we're going to enable reduction of the size of JWS payloads, avoiding the double base64url encoding is preferable to zip, which actually makes things worse.
>>>>> 
>>>>> QUESTION TO WORKING GROUP:  I'm curious whether people would like to see us enable avoiding double base64encoding of JWS payloads when they are already URL-safe.  The space savings are significant; they come at the cost of the JWS parsing becoming [part before first period . part between first and last period . part after last period] rather than the current [part before first period . part between first and second period . part after second period (with no other periods allowed)].  Opinions?
>>>>> 
>>>>> 				-- Mike
>>>>> 
>>>>> -----Original Message-----
>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dick Hardt
>>>>> Sent: Monday, October 29, 2012 8:57 AM
>>>>> To: jose@ietf.org
>>>>> Subject: [jose] signing an existing JWT
>>>>> 
>>>>> 
>>>>> Let's say we have created a JWE as such:
>>>>> 	
>>>>> 	headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritityVectorOne
>>>>> 
>>>>> This is now the payload to a JWS. Rather than increasing the token size by 4/3 by URL safe base 64 encoding the payload (since it is already URL safe), it would be useful to have a JWS header parameter that indicates the payload was not re-encoded and does not need to be URL safe base 64 decoded.
>>>>> 
>>>>> As there are more periods than expected in a JWS, decoding would ignore all periods except the first and last one for separating out the header, payload and signature.
>>>>> 
>>>>> The indicating parameter would seem to be either "tip" or "cty". I'm still confused about the difference between the two parameters, so not sure which one is appropriate.
>>>>> 
>>>>> -- Dick
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> jose@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> jose mailing list
>>>> jose@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/jose
>>> 
>> 
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>