Subject: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field?

From: Karen O'Donoghue <[email-masked]>
Date: Thu, 11 Apr 2013 19:58:53 -0400

Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 
<http://trac.tools.ietf.org/wg/jose/trac/ticket/11> proposes 
restructuring the JWE representation to remove the JWE Integrity Value 
field and instead use the RFC 5116 (AEAD) binary serialization to 
represent the Ciphertext, Initialization Vector, and Integrity Value 
values.  If this proposal is adopted, JWEs would then have three fields 
-- the header, the encrypted key, and the RFC 5116 combination of the 
Ciphertext, Initialization Vector, and Integrity Value values.

This issue is also related to issue #3.  Note that the updated McGrew 
draft described there could be used whether or not we switched to using 
RFC 5116.

Which of these best describes your preferences on this issue?

1.  Continue having separate Ciphertext, Initialization Vector, and 
Integrity Value values in the JWE representation.

2.  Switch to using the RFC 5116 (AEAD) serialization to represent the 
combination of these three values.

3.  Another resolution (please specify in detail).

0.  I need more information to decide.

Your reply is requested by Friday, April 19^th or earlier.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 11 Apr 2013 17:19:54 -0700

1

On Apr 11, 2013, at 4:58 PM, Karen O'Donoghue <[email-masked]> wrote:

> Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructuring the JWE representation to remove the JWE Integrity Value field and instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext, Initialization Vector, and Integrity Value values.  If this proposal is adopted, JWEs would then have three fields – the header, the encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization Vector, and Integrity Value values. 
> This issue is also related to issue #3.  Note that the updated McGrew draft described there could be used whether or not we switched to using RFC 5116.
>  
> 
> 1.  Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation.
> 
> 2.  Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three values.
> 
> Your reply is requested by Friday, April 19th or earlier. 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 12 Apr 2013 12:37:34 +1000

Karen,
I think this poll conflates 2 issues: a) making the integrity check value part of the ciphertext (as per RFC 5116); and b) not treating the IV in CBC-HMAC as an (app-supplied) AEAD nonce, but as part of the randomized (crypto-library-supplied) ciphertext (as per draft-mcgrew-aead-aes-cbc-hmac-sha2).

RFC 5116 “An interface and algorithms for authenticated encryption” has a nonce (N) and a separate field to the ciphertext. N is a separate input to the encryption and decryption operations.
draft-mcgrew-aead-aes-cbc-hmac-sha2 defines AEAD algorithms that take a zero-length nonce, but prefix the ciphertext with a random IV.

So my answer to the poll:

2b.
Switch to using RFC 5116.
A JWE should have separate nonce and ciphertext fields (but no separate integrity value field).
JWE should use the term “nonce”, instead of “initialization vector”.
Any integrity value that an algorithm creates should be part of the ciphertext.
When draft-mcgrew-aead-aes-cbc-hmac-sha2 is used as the AEAD algorithm the nonce field will be empty, and the ciphertext field will be a concatenation of an IV, AES output, and the truncated HMAC output.

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Karen O'Donoghue
Sent: Friday, 12 April 2013 9:59 AM
To: [email-masked]
Subject: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field?

---

From: <[email-masked]>
Date: Fri, 12 Apr 2013 08:14:58 +0200

1

From: [email-masked] [mailto:[email-masked]] On Behalf Of Karen O'Donoghue
Sent: Friday, April 12, 2013 1:59 AM
To: [email-masked]
Subject: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field?

Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructuring the JWE representation to remove the JWE Integrity Value field and instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext, Initialization Vector, and Integrity Value values.  If this proposal is adopted, JWEs would then have three fields - the header, the encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization Vector, and Integrity Value values.
This issue is also related to issue #3.  Note that the updated McGrew draft described there could be used whether or not we switched to using RFC 5116.

---

From: Roland Hedberg <[email-masked]>
Date: Sat, 13 Apr 2013 21:19:03 +0200

1

---

From: hideki nara <[email-masked]>
Date: Mon, 15 Apr 2013 16:04:13 +0900

1

2013/4/12 Karen O'Donoghue <[email-masked]>

>  Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes
> field and instead use the RFC 5116 (AEAD) binary serialization to represent
> the Ciphertext, Initialization Vector, and Integrity Value values.  If this
> proposal is adopted, JWEs would then have three fields – the header, the
> encrypted key, and the RFC 5116 combination of the Ciphertext,
> Initialization Vector, and Integrity Value values.****** **
>
> draft described there could be used whether or not we switched to using RFC
> 5116.******
>  **
>
> Which of these best describes your preferences on this issue?****
>
> Integrity Value values in the JWE representation.****
>
> combination of these three values.****
>
> 3.  Another resolution (please specify in detail).****
>
> 0.  I need more information to decide.****
>
> ** **

---

From: Mike Jones <[email-masked]>
Date: Mon, 15 Apr 2013 15:20:08 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roland Hedberg
Sent: Saturday, April 13, 2013 12:19 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field?

1

---

From: nov matake <[email-masked]>
Date: Tue, 16 Apr 2013 00:59:52 +0900

1

nov

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 15 Apr 2013 16:44:22 +0000

1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roland Hedberg
Sent: Saturday, April 13, 2013 12:19 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field?

1

---

From: Matias Woloski <[email-masked]>
Date: Mon, 15 Apr 2013 13:53:13 -0300

1

Rationale: simplicity again. As an implementer I don't want to do an extra
step of binary serialize something. Also, strings are easier to debug with
fiddler.

On Mon, Apr 15, 2013 at 1:44 PM, Anthony Nadalin <[email-masked]>wrote:

> Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we
> use RFC 5116 and remove the JWE Integrity Value field?
>
> Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we
> use RFC 5116 and remove the JWE Integrity Value field?
>
> 1
>
> proposal is adopted, JWEs would then have three fields - the header, the
> Initialization Vector, and Integrity Value values.
> 5116.

---

From: Matt Miller <[email-masked]>
Date: Mon, 15 Apr 2013 10:58:11 -0600

> When draft-mcgrew-aead-aes-cbc-hmac-sha2 is used as the AEAD algorithm the nonce field will be empty, and the ciphertext field will be a concatenation of an IV, AES output, and the truncated HMAC o…

My preference is also this 2b (or would it be 3?).

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Edmund Jay <[email-masked]>
Date: Mon, 15 Apr 2013 11:04:54 -0700 (PDT)

1

________________________________
From: Karen O'Donoghue <[email-masked]>
To: [email-masked]
Sent: Thu, April 11, 2013 4:58:56 PM
Subject: [jose] Feedback request on jose tracker issue#11: Should we use RFC 
5116 and remove the JWE Integrity Value field?

Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes     
restructuring the JWE representation to remove the JWE Integrity     Value field 
and instead use the RFC 5116 (AEAD) binary serialization     to represent the 
Ciphertext, Initialization Vector, and Integrity     Value values.  If this 
proposal is adopted, JWEs would then have     three fields – the header, the 
encrypted key, and the RFC 5116     combination of the Ciphertext, 
Initialization Vector, and Integrity     Value values.

---

From: John Bradley <[email-masked]>
Date: Mon, 15 Apr 2013 15:41:59 -0300

1 ish.

Representing the nonce/IV separately should not preclude using a crypto library generated nonce/IV , as may be done in some libraries implementing  draft-mcgrew-aead-aes-cbc-hmac-sha2.

So I am in favour of the current serialization while wanting to support the crypto from  draft-mcgrew-aead-aes-cbc-hmac-sha2 if not the particular serialization which is optimized for a different use-case.   The current draft-mcgrew-aead-aes-cbc-hmac-sha2 conflates crypto and serialization.  I am hoping we can resolve that so the crypto can be supported.

John B.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Apr 2013 10:24:12 -0400

I'm confused.  This is not about the IV == Initialization Vector, it's
about the JWE Integrity Value (inconveniently also "IV").  I don't think
anyone has proposed merging in the initialization vector, both because
that's not what RFC 5116 does and because it's a terrible idea :)

On Mon, Apr 15, 2013 at 2:41 PM, John Bradley <[email-masked]> wrote:

> 1 ish.
>
> Representing the nonce/IV separately should not preclude using a crypto
> library generated nonce/IV , as may be done in some libraries implementing
>  draft-mcgrew-aead-aes-cbc-hmac-sha2.
>
> So I am in favour of the current serialization while wanting to support
> the crypto from  draft-mcgrew-aead-aes-cbc-hmac-sha2 if not the particular
> serialization which is optimized for a different use-case.   The current draft-mcgrew-aead-aes-cbc-hmac-sha2
> conflates crypto and serialization.  I am hoping we can resolve that so the
> crypto can be supported.
>
> John B.
>
> 5116.****

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Apr 2013 13:46:27 -0400

Other protocols use ICV (Integrity Check Value) to avoid this confusion.

ICV also avoids the confusion with the many different interpretations of MAC.

Russ

On Apr 16, 2013, at 10:24 AM, Richard Barnes wrote:

> I'm confused.  This is not about the IV == Initialization Vector, it's about the JWE Integrity Value (inconveniently also "IV").  I don't think anyone has proposed merging in the initialization vector, both because that's not what RFC 5116 does and because it's a terrible idea :)
> 
>

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 17 Apr 2013 14:40:59 +0200

Hi,

1.  Continue having separate Ciphertext, Initialization
Vector, and Integrity Value values in the JWE representation.

Br,

Charles Marais.

Le 12/04/2013 01:58, Karen O'Donoghue a
écrit :

Issue #11
http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes
restructuring the JWE representation to remove the JWE Integrity
Value field and instead use the RFC 5116 (AEAD) binary
serialization to represent the Ciphertext, Initialization Vector,
and Integrity Value values.  If this proposal is adopted, JWEs
would then have three fields – the header, the encrypted key, and
the RFC 5116 combination of the Ciphertext, Initialization Vector,
and Integrity Value values.

This issue is also related to issue #3.  Note
that the updated McGrew draft described there could be used
whether or not we switched to using RFC 5116.

Which of these best
describes your preferences on this issue?

1.  Continue having
separate Ciphertext, Initialization Vector, and
Integrity Value values in the JWE representation.

2.  Switch to using the RFC 5116 (AEAD)
serialization to represent the combination of these three
values.

3.  Another
resolution (please specify in detail).

0.  I need more
information to decide.

Your reply is requested by Friday, April
19th or earlier.

--

MARAIS Charles

FT/OLNC/OLPS/ASE/IDEA/UED

Tel : 02.96.05.24.18

[email-masked]

WF004Bis / R&D Lannion / 2, avenue Pierre Marzin / 22307
LANNION Cedex - France

---

From: John Bradley <[email-masked]>
Date: Wed, 17 Apr 2013 15:29:15 -0300

Richard,

I don't understand your comment about merging the IV. 

To be clear I am asking to keep the current serialization with separate elements for Ciphertext, Initialization Vector, and Integrity Value.

I think there is some confusion around a subtle difference between RFC 5116 and draft-mcgrew-aead-aes-cbc-hmac-sha2.(Or perhaps it is just me:)

RFC 5116 has a nonce as a separate input and output I am fine with that, however it also implicitly assumes that T (Tag) is a fixed length value concatenated to the end of the cypher-text.   I am opposed to binary concatenation of the values.

draft-mcgrew goes a step further than  RFC 5116 where it basically fakes out the RFC 5116 interface by specifying the use of a zero length nonce (Sec 2.1)  It then creates a random IV  that is included as a prefix to the cypher-text (Sec 2.1-4 & 2.2-4).

By listing the IV as one of the elements that would be affected by the change some people may be thinking that the poll question also includes changing the serialization of the IV.

I am however OK with having the underlying library produce the IV as long as it provides that as an output to JWE.

As a matter of principal I prefer separating the crypto from the serialization.

Perhaps I am over thinking the question and my answer is 1.

John B.

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 18 Apr 2013 11:56:20 +1000

Matias (thanks for including a rationale with your vote),

I suspect you will have to do "an extra step of binary serialization" more often if JWE keeps the ciphertext and ICV separate.

Consider the Web Crypto API <http://www.w3.org/TR/WebCryptoAPI/#aes-gcm>. It supports an AEAD algorithm: AES GCM. To decrypt: start with a key and parameters (AAD, iv, *length* of tag); then process chunks of ciphertext; then finish.

You don't pass the authentication tag (ICV) to the API as a separate field. It is assumed to be the last bytes of the ciphertext.

Similarly for Java.

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Matias Woloski
Sent: Tuesday, 16 April 2013 2:53 AM

1

Rationale: simplicity again. As an implementer I don't want to do an extra step of binary serialize something. Also, strings are easier to debug with fiddler.

On Mon, Apr 15, 2013 at 1:44 PM, Anthony Nadalin <[email-masked]> wrote:
1

----------

----------

1

---

From: Javier Rojas Blum <[email-masked]>
Date: Thu, 18 Apr 2013 23:00:28 -0400

1

On 04/16/2013 10:24 AM, Richard Barnes wrote:
> about the JWE Integrity Value (inconveniently also "IV").  I don't 
> think anyone has proposed merging in the initialization vector, both 
> because that's not what RFC 5116 does and because it's a terrible idea :)
>
>
> On Mon, Apr 15, 2013 at 2:41 PM, John Bradley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     1 ish.
>
>     Representing the nonce/IV separately should not preclude using a
>     crypto library generated nonce/IV , as may be done in some
>     libraries implementing  draft-mcgrew-aead-aes-cbc-hmac-sha2.
>
>     So I am in favour of the current serialization while wanting to
>     support the crypto from  draft-mcgrew-aead-aes-cbc-hmac-sha2 if
>     not the particular serialization which is optimized for
>     a different use-case.   The current
>     draft-mcgrew-aead-aes-cbc-hmac-sha2 conflates crypto and
>     serialization.  I am hoping we can resolve that so the crypto can
>     be supported.
>
>     John B.
>
>     On 2013-04-11, at 8:58 PM, Karen O'Donoghue <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>>     would then have three fields -- the header, the encrypted key,
>>     and the RFC 5116 combination of the Ciphertext, Initialization
>>     Vector, and Integrity Value values.
>>
>>     This issue is also related to issue #3.  Note that the updated
>>     McGrew draft described there could be used whether or not we
>>     switched to using RFC 5116.
>>
>>     1.  Continue having separate Ciphertext, Initialization Vector,
>>     and Integrity Value values in the JWE representation.
>>
>>     2.  Switch to using the RFC 5116 (AEAD) serialization to
>>     represent the combination of these three values.
>>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Peck, Michael A" <[email-masked]>
Date: Fri, 19 Apr 2013 17:53:32 +0000

2

Some cryptographic modes don't have a separate initialization vector or don't have a separate integrity check value.

The RFC5116 approach encourages shifting the complexity of handling crypto to the crypto library rather than the JOSE implementation.
i.e. Give the crypto library a ciphertext with embedded integrity check value and know that the crypto library will reject decryption if the integrity check fails, rather than trusting each JOSE implementation to properly check the integrity check value.

As already pointed out the question isn't quite phrased correctly because RFC 5116 has a separate initialization vector field, it's just not used by draft-mcgrew-aead-aes-cbc-hmac-sha2-01.

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Karen O'Donoghue
Sent: Thursday, April 11, 2013 7:59 PM
To: [email-masked]
Subject: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field?

---

From: "Salvatore D'Agostino" <[email-masked]>
Date: Fri, 19 Apr 2013 22:41:25 -0400

1

Sal D'Agostino

Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes 
restructuring the JWE representation to remove the JWE Integrity Value field 
and instead use the RFC 5116 (AEAD) binary serialization to represent the 
Ciphertext, Initialization Vector, and Integrity Value values.  If this 
proposal is adopted, JWEs would then have three fields - the header, the 
encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization 
Vector, and Integrity Value values.
This issue is also related to issue #3.  Note that the updated McGrew draft 
described there could be used whether or not we switched to using RFC 5116.

1.  Continue having separate Ciphertext, Initialization Vector, and Integrity 
Value values in the JWE representation.