Subject: [jose] Dealing with Issue #8 - Direct mode for key agreement

From: "Jim Schaad" <[email-masked]>
Date: Wed, 29 May 2013 16:34:18 -0700

<chair>

At the F2F meeting in April we discussed this issue.  At that time there was
a task that was assigned to the Chairs.  I am finally getting around to
this.

There are currently two methods for going from a key agreement operation to
a content encryption key in JWE.  One of the questions that was asked -
should we simplify this so that there is only one method to do this.

Method #1

Key Agreement Secret --(KDF)--> Key Encryption Key --(Key Wrap)--> Content
Encryption Key

Method #2

Key Agreement Secret --(KDF)--> Content Encryption Key.

At this point the chairs are NOT interested in answering the question -
should we remove the second method.  What we want to know at this point are
answers to the following question:

I have a use case where doing Method #2 is the correct method or a much
better method.  If this is a true statement, please provide the use case to
use.  

If you don't have a use case then we currently do not need a reply to this
message.

Jim

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 30 May 2013 09:25:06 +0200

> [...] question:

I think I have a use case where method #2 is better. I'm working on
processing JWE objects on constrained devices and transferring them over
low capacity networks. If my understanding of method #2 is correct, it
would leave the JWE Encrypted Key empty, thus reducing the size of the
JWE message.
I therefore think method #2 is preferable for this use case, since it
saves both bandwidth and RAM on the constrained device.

Regards,

Ludwig Seitz

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2 
Scheelevägen 17 
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 May 2013 11:00:24 -0400

The difference we're talking about is 16 bytes, ~20 when base64 encoded.
 Is that enough to be a significant difference for you?

On Thu, May 30, 2013 at 3:25 AM, Ludwig Seitz <[email-masked]> wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 30 May 2013 11:14:03 -0400

> saves both bandwidth and RAM on the constrained device.

Is this always a pairwise communication?  If the message is ever intended to be decrypted by two or more parties, then you need Method #1.  If there are every instances of more than one recipient, then you need to have the code and memory for Method #1 anyway.  And, as Richard already pointed out, it is not a lot of memory.

Russ

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 31 May 2013 13:11:03 +0200

On Thu, 2013-05-30 at 11:14 -0400, Russ Housley wrote:
> Is this always a pairwise communication?  If the message is ever intended to 
> be decrypted by two or more parties, then you need Method #1.  If there are 
> every instances of more than one recipient, then you need to have the code 
> and memory for Method #1 anyway.  And, as Richard already pointed out, it is not a lot of memory.

Thank you for your comments Richard and Russ.

I'm thinking about securing parts of RESTful requests and responses
transferred using the CoAP protocol. I can safely assume the responses
are only for one recipient, with the requests you could construct a use
case where the same request is broadcasted to a number of devices, however 
doing this using method #1 would probably preclude the use of JOSE on a whole class 
of devices (since even with compact notation the overhead introduced is quite significant).

For CoAP, a maximum message size of roughly 1024 bytes can be assumed (see section
4.6 of draft-ietf-core-coap-17). In that case ~20 bytes more may not
seem so bad, but on the other hand if you look at the underlying 
adaptation layer, with e.g. 6LoWPAN L2 packets, which are limited to 127 bytes, this
becomes quite relevant. Furthermore we expect the JWE protected payload to be quite small
(typically not larger than the blocksize of the cipher) and in that case ~20 bytes of overhead 
would almost double the size of the payload.

Perhaps this kind of scenario calls for a specific JOSE profile? Or do you think JOSE is not the right 
approach for what I'm trying to achieve? I'd be grateful for any comments and suggestions.

Regards,

Ludwig Seitz

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2 
Scheelevägen 17 
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 31 May 2013 16:06:20 -0700

Ludwig,

You should definitely look at the current small devices case in the use cases document.  It was written with one set of cases in mind, however your cases may differ somewhat.  Your comments would be appreciated.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ludwig Seitz
> Sent: Friday, May 31, 2013 4:11 AM
> To: [email-masked]
> Subject: Re: [jose] Dealing with Issue #8 - Direct mode for key agreement
> 
> > >> Key Agreement Secret --(KDF)--> Key Encryption Key --(Key Wrap)-->
> > >> Content Encryption Key
> > >>
> > >> Method #2
> > >>
> > >> I have a use case where doing Method #2 is the correct method or a
> > >> much better method.  If this is a true statement, please provide
> > >> the use case to use.
> > >
> > > processing JWE objects on constrained devices and transferring them
> > > over low capacity networks. If my understanding of method #2 is
> > > correct, it would leave the JWE Encrypted Key empty, thus reducing
> > > the size of the JWE message.
> > > I therefore think method #2 is preferable for this use case, since
> > > it saves both bandwidth and RAM on the constrained device.
> >
> > Is this always a pairwise communication?  If the message is ever
> > intended to be decrypted by two or more parties, then you need Method
> > #1.  If there are every instances of more than one recipient, then you
> > need to have the code and memory for Method #1 anyway.  And, as
> Richard already pointed out, it is not a lot of memory.
> 
> transferred using the CoAP protocol. I can safely assume the responses are
> only for one recipient, with the requests you could construct a use case
> where the same request is broadcasted to a number of devices, however
> doing this using method #1 would probably preclude the use of JOSE on a
> whole class of devices (since even with compact notation the overhead
> introduced is quite significant).
> 
> 4.6 of draft-ietf-core-coap-17). In that case ~20 bytes more may not seem so
> bad, but on the other hand if you look at the underlying adaptation layer,
> with e.g. 6LoWPAN L2 packets, which are limited to 127 bytes, this becomes
> quite relevant. Furthermore we expect the JWE protected payload to be
> quite small (typically not larger than the blocksize of the cipher) and in that
> case ~20 bytes of overhead would almost double the size of the payload.
> 
> Perhaps this kind of scenario calls for a specific JOSE profile? Or do you think
> JOSE is not the right approach for what I'm trying to achieve? I'd be grateful
> for any comments and suggestions.
> 
> Regards,
> 
> Ludwig Seitz
> 
> 
> --
> Ludwig Seitz, PhD
> SICS Swedish ICT AB
> Ideon Science Park
> Building Beta 2
> Scheelev gen 17
> SE-223 70 Lund
> 
> Phone +46(0)70-349 92 51
> http://www.sics.se

---

From: Mike Jones <[email-masked]>
Date: Fri, 31 May 2013 23:25:53 +0000

+1

Ludwig, your timing is good, since the Use Cases document is in Working Group Last Call.  It would be great if you could write a few paragraphs describing your use case to add to the document.

				Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Friday, May 31, 2013 4:06 PM
To: 'Ludwig Seitz'; [email-masked]
Subject: Re: [jose] Dealing with Issue #8 - Direct mode for key agreement

Ludwig,

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Ludwig Seitz
> > >> Key Agreement Secret --(KDF)--> Key Encryption Key --(Key 
> > >> Wrap)--> Content Encryption Key
> > >>
> > >> Method #2
> > >>
> > >> I have a use case where doing Method #2 is the correct method or 
> > >> a much better method.  If this is a true statement, please 
> > >> provide the use case to use.
> > >
> > > I think I have a use case where method #2 is better. I'm working 
> > > on processing JWE objects on constrained devices and transferring 
> > > them over low capacity networks. If my understanding of method #2 
> > > is correct, it would leave the JWE Encrypted Key empty, thus 
> > > reducing the size of the JWE message.
> > intended to be decrypted by two or more parties, then you need 
> > Method #1.  If there are every instances of more than one recipient, 
> > then you need to have the code and memory for Method #1 anyway.  
> > And, as
> are only for one recipient, with the requests you could construct a 
> use case where the same request is broadcasted to a number of devices, 
> however doing this using method #1 would probably preclude the use of 
> JOSE on a whole class of devices (since even with compact notation the 
> overhead introduced is quite significant).
> 
> adaptation layer, with e.g. 6LoWPAN L2 packets, which are limited to 
> 127 bytes, this becomes quite relevant. Furthermore we expect the JWE 
> protected payload to be quite small (typically not larger than the 
> blocksize of the cipher) and in that case ~20 bytes of overhead would almost double the size of the payload.
> 
> Perhaps this kind of scenario calls for a specific JOSE profile? Or do 
> you think JOSE is not the right approach for what I'm trying to 
> achieve? I'd be grateful for any comments and suggestions.
> 
> Regards,
> 
> Ludwig Seitz
> 
> 
> --
> Ludwig Seitz, PhD
> SICS Swedish ICT AB
> Ideon Science Park
> Building Beta 2
> Scheelev gen 17
> SE-223 70 Lund
> 
> Phone +46(0)70-349 92 51
> http://www.sics.se