Re: [jose] Reducing the size of JWS payloads

"Manger, James H" <James.H.Manger@team.telstra.com> Wed, 19 December 2012 23:40 UTC

Return-Path: <James.H.Manger@team.telstra.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 ADB2C21F88A2 for <jose@ietfa.amsl.com>; Wed, 19 Dec 2012 15:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.761
X-Spam-Level:
X-Spam-Status: No, score=-0.761 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
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 B0etbXDiLTGA for <jose@ietfa.amsl.com>; Wed, 19 Dec 2012 15:40:13 -0800 (PST)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3287B21F8898 for <jose@ietf.org>; Wed, 19 Dec 2012 15:40:12 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,320,1355058000"; d="scan'208";a="109151396"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 20 Dec 2012 10:40:11 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6931"; a="103055968"
Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdvi.tcif.telstra.com.au with ESMTP; 20 Dec 2012 10:40:09 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Thu, 20 Dec 2012 10:40:10 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Mike Jones <Michael.Jones@microsoft.com>, "jose@ietf.org" <jose@ietf.org>
Date: Thu, 20 Dec 2012 10:40:09 +1100
Thread-Topic: Reducing the size of JWS payloads
Thread-Index: Ac3dkDn1ScBaTFOCSwGyAjfBe1wGHgArYb9Q
Message-ID: <255B9BB34FB7D647A506DC292726F6E115041F65F9@WSMSG3153V.srv.dir.telstra.com>
References: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436696B341@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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 23:40:14 -0000

I don't think your calculations are not quite right, Mike.

Deflating the 526 character JWE example from appendix 2 gives 427 bytes, not the 536 you state.

Assuming a JWS header and signature is 365 chars (2048-bit RSA key, as per JWS appendix 2).

JWS_today(JWE) = 365 + B64(526) = 1067
JWS_zip(JWE) = 365 + 15 + B64(427) = 950 = save 117 chars (11%)
JWS_no_b64(JWE) = 365 + 15 + 526 = 906 = save 161 chars (15%)

So "APPLYING DEFLATE TO THE PAYLOAD" does not make things worse, it gives a 11% saving.

These numbers are not that relevant as I agree with John Bradley that an asymmetric signature is more likely to be applied before the encryption.

I suspect JOSE would be better off defining its operations on byte arrays: the first byte array is a JSON object, another byte array is the content; signing covers these byte arrays (with a length) etc. Then leave the base64url encoding to the very last step (after any crypto).

--
James Manger

> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Mike Jones
> Sent: Wednesday, 19 December 2012 1:26 PM
> To: jose@ietf.org
> Cc: Dick Hardt
> Subject: [jose] Reducing the size of JWS payloads
> 
> 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?