Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E69E1B2ECD for ; Tue, 8 Dec 2015 07:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 mU8p1_TSzXGo for ; Tue, 8 Dec 2015 07:00:16 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA0D1B2EB7 for ; Tue, 8 Dec 2015 07:00:15 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-90-5666f07dcecc Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 42.0D.04914.D70F6665; Tue, 8 Dec 2015 16:00:13 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.149]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 16:00:12 +0100 From: Francesca Palombini To: "cose@ietf.org" Thread-Topic: Message size considerations Thread-Index: AdExx8w+7Fl8oavJQAC+jbJdBuSmQg== Date: Tue, 8 Dec 2015 15:00:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D2736FF6C4A3F3428982D3508DD478DE0D42B753ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2K7t27th7Qwg7NrJS2mbZ3K6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAUdM5gKvrxjrOi9vpa9gfHVBcYuRk4OCQETiU0n77FD2GIS F+6tZ+ti5OIQEjjMKDHh/BQWCGcxo8SXq5+YQKrYBGwkLjx8zwpiiwgoS0w61gxmCwuoSHyb dJYdIq4psbRpJpStJ9H4/SaQzcHBAlTzZJE0SJhXwFfi17vDbCA2I9Di76fWgI1nFhCXuPVk PhPEQQISS/acZ4awRSVePv7HCjJGQkBRYnm/HER5vsT/681sECMFJU7OfMIygVFoFpJJs5CU zUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxihanFhfnphsZ66UWZSYXF+fn6eWl lmxiBEbFwS2/dXcwrn7teIhRgINRiYfX4HpqmBBrYllxZe4hRgkOZiURXitgTAnxpiRWVqUW 5ccXleakFh9ilOZgURLnbWF6ECokkJ5YkpqdmlqQWgSTZeLglGpgjEu/d2D3RM8encurLh6w 0uFumBQTs1FFXvLDnf2+9V6XFO5/CSl4seSEsM/BvikT0uUVC5j92WQfJsfcOjbZklV0Zazt sqvHEnYZmHcaBTWts9tss/DRIfXbs/fySbVNZp8RyFH3bta17kVuR+ue8OQdZGfQP7SvbpX9 6buZd1ictl/b4vs6SYmlOCPRUIu5qDgRAEzVkumGAgAA Archived-At: Subject: [COSE] Message size considerations X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 15:00:26 -0000 --_000_D2736FF6C4A3F3428982D3508DD478DE0D42B753ESESSMB205erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have re-calculated the message sizes for the different use cases that ar= e relevant for OSCOAP [1], based on draft-ietf-cose-msg-08 (see column "ove= rhead cose-msg-08" of table below). We think that the COSE_Encrypt format is well designed for applications whi= ch have tight requirements on message size, the overhead being of the order= of 10 bytes (excluding tag and necessary header parameters of size which d= epends on application). We don't see any reason why we should get twice the= overhead if we MAC or Sign a message instead. In this mail we propose some optimizations that mainly have an impact on th= e other formats, see column "overhead with mod" in the table below. In order to decrease the message size overhead we propose to add 2 new mess= age types: one for single signature (1) (in our use case we don't need mult= iple signatures), and one for MAC with no recipient (2). The rest of the mail is discussing the optimizations and our proposal. We t= hought to start this discussion here in the mailing list, but we could also= add our requests in the issue tracker if it is preferred. Reading up on the discussion about COSE structure for single signer [2], [3= ], we could not find any "closure" to that discussion, and like to revisit = the topic again. Analogously to the COSE_Encrypted structure, we consider that all informati= on necessary for the cryptographic operations is pre-established between th= e endpoints. The Context Identifier sent protected in the message is enough= to identify the security context and all the parameters necessary for cryp= to computations (alg, key, etc) previously set up in the endpoints. Because= of that, we don't need to send the signer/recipient info in the message, a= nd we suggest to optimize the COSE structure for this use case. We propose the following modifications: a. remove the alg parameter from the message sent: since all information is= pre-established in the nodes' security context, we don't need to send the = alg in the message. (saves 2B) b. for the new single-signature structure (1), we only need to send the bts= tr 'signature', we can remove the 'signatures' and 'COSE_signature' structu= re. The Context Identifier and the Sequence Number are sent in the COSE_Sig= n protected header. (saves 5B) c. remove the recipient structure from the new MAC structure (2). (saves 8B= ) d. as for b, for the COSE_Encrypt with counter signature use case, we propo= se to give the choice to use the whole COSE_Signature structure or only the= btstr 'signature' as 'counter signature'. If we only send the btstr 'signature' (our use case), we assume that the al= g for counter signature is also defined in the security context. (saves 8B) Even if these improvements may seem small, please note that in some cases t= he difference is half the total overhead, which is not insignificant. Table: Message overhead +--------------+-------------+----------+------------+ | COSE | overhead | overhead | difference | | Structure | cose-msg-08 | with mod | | +--------------+-------------+----------+------------+ | COSE_Sign | 18 B | 11 B | 7 B | +--------------+-------------+----------+------------+ | COSE_Encrypt | 11 B | 9 B | 2 B | +--------------+-------------+----------+------------+ | COSE_Mac | 20 B | 10 B | 10 B | +--------------+-------------+----------+------------+ | COSE_Encrypt | 20 B | 12 B | 8 B | | +counter sig | | | | +--------------+-------------+----------+------------+ As a summary, this is how we would modify the COSE_Message structures in or= der to optimize the message size, and how many bytes we would save from eac= h modification: COSE_Sign: [protected, unprotected, payload, [[ protected, unprotected, sig= nature]]] Bytes removed: -2B(b) -1B(b) -4B(a,b) COSE_Sign single signature (new type): [protected, unprotected, payload, si= gnature] COSE_Mac: [protected, unprotected, payload, tag, [[ protected, unprotected,= ciphertext]]] Bytes removed: -2B(a) -2B(c) -1B(c) -4B(a,c) = -1B(c) COSE_Mac no recipient (new type): [protected, unprotected, payload, tag] COSE_Encrypt: [protected, unprotected, ciphertext] Bytes removed: -2B(a) COSE_Encrypt: [protected, unprotected, ciphertext] COSE_Encrypt with counter signature: [protected, {7:[protected, unprotected= , signature], ...}, ciphertext] Bytes removed: -2B(a) -1B(d) -1B(d) -4B(a,d) COSE_Encrypt with counter signature mod: [protected, {7: signature, ...}, c= iphertext] To meet Jim's arguments against b. and c. in his previous message [2] (most= recent message I could find about this topic): "4. There is currently a very clear cut rule about things only being used = at the layer they are placed in. This means that currently key identifiers= are never placed in the same layer as a content key algorithm. This would= be broken by the proposal put forth. I worry that once this is done, ther= e will be more items than kid that will migrate between layers. One of the= things that I never liked in the JOSE proposals what the number of places = that one needed to look for the various control fields. Currently in COSE = this is limited to two places. If we introduce the possibility of cross la= yer contamination then this number might grow in the future to deal with im= plementation faults. One of the way that these faults might develop is for designers to say - I = think that this should be authenticated, and thus will put it at the wrong = layer to ensure that it is. Either without thinking about the question - s= hould it be authenticated, or a different algorithm be required so that aut= hentication is possible." We suggest to have one layer only for this specific use case where we don't= use this recipient/signer structure anyway, in new structures adapted for = this use case. We are not proposing to change the current structures, which= would be used when recipient/signer structures are necessary. "5. Code size is going to be very different if two different methods of de= aling with structure needs to be supported. It is currently being assumed = that direct key is going to be the major use case in a number of situations= . If this is not the case then current proposals do not help the situation = any. If it is true that more than one method of key management needs to be supported then the code size is going to grow because of the need to suppor= t an additional way that key management is going to be done." In our particular application of COSE, we don't need to support use cases w= ith recipient/signer structures. The creation of different msg types as we = suggest should make implementation easier. Francesca [1] https://tools.ietf.org/html/draft-selander-ace-object-security-03 [2] https://mailarchive.ietf.org/arch/msg/cose/j1P3Nqt1wEZSTGCYO0gFSeazxUY [3] https://mailarchive.ietf.org/arch/msg/cose/8fKGZBMZuUmvJafwQodKqMxQGbc --_000_D2736FF6C4A3F3428982D3508DD478DE0D42B753ESESSMB205erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

 

We have re-calculated the message sizes for the different us= e cases that are relevant for OSCOAP [1], based on draft-ietf-cose-msg-08 (= see column “overhead cose-msg-08” of table below).

 

We think that the COSE_Encrypt format is well designed for a= pplications which have tight requirements on message size, the overhead bei= ng of the order of 10 bytes (excluding tag and necessary header parameters of size which depends on application). We don't see any = reason why we should get twice the overhead if we MAC or Sign a message ins= tead.

 

In this mail we propose some optimizations that mainly have = an impact on the other formats, see column “overhead with mod” = in the table below.

 

In order to decrease the message size overhead we propose to= add 2 new message types: one for single signature (1) (in our use case we = don't need multiple signatures), and one for MAC with no recipient (2).

 

The rest of the mail is discussing the optimizations and our= proposal. We thought to start this discussion here in the mailing list, bu= t we could also add our requests in the issue tracker if it is preferred.

 

 

 

Reading up on the discussion about COSE structure for single= signer [2], [3], we could not find any "closure" to that discuss= ion, and like to revisit the topic again.

 

Analogously to the COSE_Encrypted structure, we consider tha= t all information necessary for the cryptographic operations is pre-establi= shed between the endpoints. The Context Identifier sent protected in the message is enough to identify the security context a= nd all the parameters necessary for crypto computations (alg, key, etc) pre= viously set up in the endpoints. Because of that, we don't need to send the= signer/recipient info in the message, and we suggest to optimize the COSE structure for this use case.

 

 

We propose the following modifications:

 

a. remove the alg parameter from the message sent: since all= information is pre-established in the nodes' security context, we don't ne= ed to send the alg in the message. (saves 2B)

 

b. for the new single-signature structure (1), we only need = to send the btstr 'signature', we can remove the 'signatures' and 'COSE_sig= nature' structure. The Context Identifier and the Sequence Number are sent in the COSE_Sign protected header. (saves 5B)

 

c. remove the recipient structure from the new MAC structure= (2). (saves 8B)

 

d. as for b, for the COSE_Encrypt with counter signature use= case, we propose to give the choice to use the whole COSE_Signature struct= ure or only the btstr 'signature' as ‘counter signature’.<= /o:p>

If we only send the btstr 'signature' (our use case), we ass= ume that the alg for counter signature is also defined in the security cont= ext. (saves 8B)

 

 

Even if these improvements may seem small, please note that = in some cases the difference is half the total overhead, which is not insig= nificant.

 

 

Table: Message overhead

 

+--------------+-------------+----------+---= ---------+

|      COSE    |&nbs= p; overhead   | overhead | difference |

|  Structure   | cose-msg-08 | with mod |&nbs= p;           |=

+--------------+-------------+----------+---= ---------+

| COSE_Sign    |     18 B=     |   11 B   |    = 7 B    |

+--------------+-------------+----------+---= ---------+

| COSE_Encrypt |     11 B  &nb= sp; |    9 B   |     2 B =    |

+--------------+-------------+----------+---= ---------+

| COSE_Mac     |    = 20 B    |   10 B   |    = 10 B    |

+--------------+-------------+----------+---= ---------+

| COSE_Encrypt |     20 B  &nb= sp; |   12 B   |     8 B  = ;  |

| +counter sig |      &nbs= p;      |       = ;   |          =   |

+--------------+-------------+----------+---= ---------+

 

 

As a summary, this is how we would modify the COSE_Message s= tructures in order to optimize the message size, and how many bytes we woul= d save from each modification:

 

COSE_Sign: [protected, unprotected, payload, [[ protected, u= nprotected, signature]]]

Bytes removed:       &nbs= p;            &= nbsp;        -2B(b) -1B(b)  &n= bsp;  -4B(a,b)

 

COSE_Sign single signature (new type): [protected, unprotect= ed, payload, signature]

 

 

COSE_Mac: [protected, unprotected, payload, tag, [[ protecte= d, unprotected, ciphertext]]]

Bytes removed:       &nbs= p;   -2B(a)         =       -2B(c) -1B(c)     -4B(a,= c)    -1B(c)

 

COSE_Mac no recipient (new type): [protected, unprotected, p= ayload, tag]

 

 

COSE_Encrypt: [protected, unprotected, ciphertext]

Bytes removed:   -2B(a)

 

COSE_Encrypt: [protected, unprotected, ciphertext]

 

 

COSE_Encrypt with counter signature: [protected, {7:[protect= ed, unprotected, signature], …}, ciphertext]

Bytes removed:       &nbs= p;            &= nbsp;     -2B(a)  -1B(d) -1B(d)    = -4B(a,d)

 

COSE_Encrypt with counter signature mod: [protected, {7: sig= nature, …}, ciphertext]

 

 

To meet Jim's arguments against b. and c. in his previous me= ssage [2] (most recent message I could find about this topic):

 

"4.  There is currently a very clear cut rule abou= t things only being used at the layer they are placed in.  This means = that currently key identifiers are never placed in the same layer as a content key algorithm.  This would be broken by the proposal put= forth.  I worry that once this is done, there will be more items than= kid that will migrate between layers.  One of the things that I never= liked in the JOSE proposals what the number of places that one needed to look for the various control fields.  Curre= ntly in COSE this is limited to two places.  If we introduce the possi= bility of cross layer contamination then this number might grow in the futu= re to deal with implementation faults.  

One of the way that these faults might develop is for design= ers to say - I think that this should be authenticated, and thus will put i= t at the wrong layer to ensure that it is.  Either without thinking about the question - should it be authenticated, or a dif= ferent algorithm be required so that authentication is possible."=

 

We suggest to have one layer only for this specific use case= where we don't use this recipient/signer structure anyway, in new structur= es adapted for this use case. We are not proposing to change the current structures, which would be used when recipient/signe= r structures are necessary.

 

"5.  Code size is going to be very different if tw= o different methods of dealing with structure needs to be supported.  = It is currently being assumed that direct key is going to be the major use case in a number of situations. If this is not the case then cur= rent proposals do not help the situation any.  If it is true that more= than one method of key management needs to be

supported then the code size is going to grow because of the= need to support an additional way that key management is going to be done.= "

 

In our particular application of COSE, we don't need to supp= ort use cases with recipient/signer structures. The creation of different m= sg types as we suggest should make implementation easier.

 

Francesca

 

 

[1] https://tools.ietf.org/html/draft-selander-ace-object-security-03<= /o:p>

 

[2] https://mailarchive.ietf.org/arch/msg/cose/j1P3Nqt1wEZSTGCYO0gFSeazxUY<= o:p>

 

[3] https://mailarchive.ietf.org/arch/msg/cose/8fKGZBMZuUmvJafwQodKqMxQGbc<= o:p>

 

 

--_000_D2736FF6C4A3F3428982D3508DD478DE0D42B753ESESSMB205erics_--