Subject: [jose] Comments on version 11 of draft-ietf-jose-json-web-encryption

From: "Jim Schaad" <[email-masked]>
Date: Sat, 15 Jun 2013 14:08:02 -0700

Gentlemen,

Here are a few comments for consideration.  Note that some of the comments
from the JWS review are also applicable to this document as much of the
language in places is the same.

1.  In Section 4.1.2 - You probably want to say an AEAD algorithm not an AE
algorithm

2  In section 4.1.3 - I would suggest changing the text to "This parameter
MUST be omitted unless required by the algorithm in the "alg" member.  This
header parameter MUST be understood if an algorithm is supported that
requires it."

3.  In section 4.1.4 - Does the group agree that compression is a required
feature to implement?

4.  Why not reference sections 4.1.5 - 10 by reference with a comment that
these refer to the key that was used to encrypt the content?  Is there a
benefit of having them listed here?  Is there a difference in the way they
are interpreted other than the recipient/originator thing?

5.  Why not reference sections 4.1.11-12 from the JWS document?  Is there a
difference in the way they are interpreted?

6.  If we are not going with an alphabetic order of names, the I would
suggest that apu should be next to exp as they are used in the same context
and therefore having them adjacent makes sense.

7.  Is there a reason not to reference 4.1.14 from JWS?  Is there a
difference in interpretation?

Jim

---

From: Mike Jones <[email-masked]>
Date: Thu, 27 Jun 2013 22:50:01 +0000

Thanks for the useful review comments, Jim.  Replies inline prefixed by "Mike>"...

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Saturday, June 15, 2013 2:08 PM
To: [email-masked]
Cc: [email-masked]
Subject: Comments on version 11 of draft-ietf-jose-json-web-encryption

Gentlemen,

Here are a few comments for consideration.  Note that some of the comments from the JWS review are also applicable to this document as much of the language in places is the same.

1.  In Section 4.1.2 - You probably want to say an AEAD algorithm not an AE algorithm

Mike> The problem with the "AEAD" terminology is that it implies both algorithm and encoding properties.  We want the algorithm properties but not the encoding properties defined by RFC 5116.  Thus, a conscious terminology change was made in -08 to longer use the term "AEAD".

2  In section 4.1.3 - I would suggest changing the text to "This parameter MUST be omitted unless required by the algorithm in the "alg" member.  This header parameter MUST be understood if an algorithm is supported that requires it."

Mike> OK

3.  In section 4.1.4 - Does the group agree that compression is a required feature to implement?

Mike> This feature was discussed at IETF 83 and has been in place in the current form ever since -02.  I'd be shocked if people didn't believe this feature was necessary.

4.  Why not reference sections 4.1.5 - 10 by reference with a comment that these refer to the key that was used to encrypt the content?  Is there a benefit of having them listed here?  Is there a difference in the way they are interpreted other than the recipient/originator thing?

Mike> I assume you mean reference them in JWS?  There's a complete list here so that it's clear to JWE implementers what the reserved header parameters are without having to reference other specs.  And yes, the JWS and JWE key selection parameters are the same other than the JWS sender/JWE receiver difference.

5.  Why not reference sections 4.1.11-12 from the JWS document?  Is there a difference in the way they are interpreted?

Mike> (Apparently I didn't understand what you were suggesting in 4, having seen this next question.)  In any event, in JWS they reference the key that is used to verify the signature.  In JWE they reference the key to which the content was encrypted.  That's the difference in all these parameters.

6.  If we are not going with an alphabetic order of names, the I would suggest that apu should be next to exp as they are used in the same context and therefore having them adjacent makes sense.

Mike> Actually, Richard had suggested moving "apu" to the key agreement section in JWA, since its use is algorithm-specific.  I think I agree with him.

7.  Is there a reason not to reference 4.1.14 from JWS?  Is there a difference in interpretation?

Mike> Stylistically, it seems easier for implementers of JWE to have a complete list of general-purpose parameter definitions than to have some here and some there.  The example is also different, because one is a JWS header and the other is a JWE header.

                                                                Thanks again,

                                                                -- Mike

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 28 Jun 2013 12:39:19 -0700

From: Mike Jones [mailto:[email-masked]] 
Sent: Thursday, June 27, 2013 3:50 PM
To: Jim Schaad
Cc: [email-masked]
Subject: RE: Comments on version 11 of draft-ietf-jose-json-web-encryption

Thanks for the useful review comments, Jim.  Replies inline prefixed by
"Mike>".

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Saturday, June 15, 2013 2:08 PM
To: [email-masked]
Cc: [email-masked]
Subject: Comments on version 11 of draft-ietf-jose-json-web-encryption

Gentlemen,

Mike> The problem with the "AEAD" terminology is that it implies both
algorithm and encoding properties.  We want the algorithm properties but not
the encoding properties defined by RFC 5116.  Thus, a conscious terminology
change was made in -08 to longer use the term "AEAD".

[JLS] The term AEAD has nothing to do with the encoding properties defined
in RFC 5116.  AE and AEAD algorithms are very distinct.  One offers only
authenticated encryption and the other adds the associated data.  They are
not to be confused.

Mike> This feature was discussed at IETF 83 and has been in place in the
current form ever since -02.  I'd be shocked if people didn't believe this
feature was necessary.

[JLS]  So in your opinion, it is an absolute requirement that my code
implement zip, but not that it implement jwk.  This makes absolutely no
sense to me.  I am not asking if there is a requirement that it be present
in the document.  I am asking if it is a required to implement feature.

Mike> I assume you mean reference them in JWS?  There's a complete list here
so that it's clear to JWE implementers what the reserved header parameters
are without having to reference other specs.  And yes, the JWS and JWE key
selection parameters are the same other than the JWS sender/JWE receiver
difference.

[JLS] That does not make sense to me.  There are lots of times that
referencing other specifications makes a lot of sense.  You certainly be
that this is true when it comes to security considerations.  I believe that
it is equally true here.  I did not say don't list time, I said that you
should reference the sections in the signature draft.

Mike> (Apparently I didn't understand what you were suggesting in 4, having
seen this next question.)  In any event, in JWS they reference the key that
is used to verify the signature.  In JWE they reference the key to which the
content was encrypted.  That's the difference in all these parameters.

Mike> Actually, Richard had suggested moving "apu" to the key agreement
section in JWA, since its use is algorithm-specific.  I think I agree with
him.

[JLS] that's a fine approach as well.

Mike> Stylistically, it seems easier for implementers of JWE to have a
complete list of general-purpose parameter definitions than to have some
here and some there.  The example is also different, because one is a JWS
header and the other is a JWE header.

                                                                Thanks
again,

                                                                -- Mike

Jim

---

From: Mike Jones <[email-masked]>
Date: Fri, 28 Jun 2013 23:45:22 +0000

Responses inline...

From: Jim Schaad [mailto:[email-masked]]
Sent: Friday, June 28, 2013 12:39 PM
To: Mike Jones
Cc: [email-masked]
Subject: RE: Comments on version 11 of draft-ietf-jose-json-web-encryption

From: Mike Jones [mailto:[email-masked]]
Sent: Thursday, June 27, 2013 3:50 PM
To: Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Comments on version 11 of draft-ietf-jose-json-web-encryption

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Saturday, June 15, 2013 2:08 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Comments on version 11 of draft-ietf-jose-json-web-encryption

Gentlemen,

[JLS] The term AEAD has nothing to do with the encoding properties defined in RFC 5116.  AE and AEAD algorithms are very distinct.  One offers only authenticated encryption and the other adds the associated data.  They are not to be confused.

Mike> OK - What's a good reference for the term that's not RFC 5116?

[JLS]  So in your opinion, it is an absolute requirement that my code implement zip, but not that it implement jwk.  This makes absolutely no sense to me.  I am not asking if there is a requirement that it be present in the document.  I am asking if it is a required to implement feature.

Mike> The rationale for this is that people (Eric Rescorla, I think) thought that since "zip" processing changes the ciphertext, that not supporting it would give a weapon to attackers, enabling them to substitute one ciphertext for another.  Since there are security implications in not implementing it, it's MTI.

[JLS] That does not make sense to me.  There are lots of times that referencing other specifications makes a lot of sense.  You certainly be that this is true when it comes to security considerations.  I believe that it is equally true here.  I did not say don't list time, I said that you should reference the sections in the signature draft.

Mike> I have no objection to adding a reference saying that related parameter definitions are also contained in JWS 4.1.2 - 4.1.5.

Mike> I have no objection to adding a reference saying that the related parameter definitions are also contained in JWS 4.1.8 - 4.1.9.

Mike> I have no objection to adding a reference saying that the related parameter definition is also contained in JWS 4.1.10.

                                                                Thanks again,

                                                                -- Mike

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 28 Jun 2013 20:38:50 -0700

From: Mike Jones [mailto:[email-masked]] 
Sent: Friday, June 28, 2013 4:45 PM
To: Jim Schaad
Cc: [email-masked]
Subject: RE: Comments on version 11 of draft-ietf-jose-json-web-encryption

Responses inline.

 

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Saturday, June 15, 2013 2:08 PM
To: [email-masked]
Cc: [email-masked]
Subject: Comments on version 11 of draft-ietf-jose-json-web-encryption

Gentlemen,

[JLS] You don't need one - if you are worried about it rather than just
doing an inline abbrev (i.e. Authenticated Encryption with Associated Data
(AEAD)) then define it in the terms.

Mike> The rationale for this is that people (Eric Rescorla, I think) thought
that since "zip" processing changes the ciphertext, that not supporting it
would give a weapon to attackers, enabling them to substitute one ciphertext
for another.  Since there are security implications in not implementing it,
it's MTI.

[JLS] I would have to talk to EKR about this.  Given that you compress
before you encrypt and we are authenticating either the post encrypted
stream or the post compressed stream I don't see where this is a real
security issue.

Mike> I have no objection to adding a reference saying that related
parameter definitions are also contained in JWS 4.1.2 - 4.1.5.

[JLS] I have no objection to saying the complete definition is in JWS as the
entire text of the section.

Mike> I have no objection to adding a reference saying that the related
parameter definitions are also contained in JWS 4.1.8 - 4.1.9.

Mike> I have no objection to adding a reference saying that the related
parameter definition is also contained in JWS 4.1.10.

                                                                Thanks
again,

                                                                -- Mike

Jim