Subject: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption

From: David McGrew <[email-masked]>
Date: Tue, 15 Nov 2011 04:40:12 -0800

Hi

I would like to contribute the following comments.  I have not been  
closely following the WG, so apologies in advance if I'm rehashing  
something.

The json-web-signature draft should be changed by using the more  
generic "authentication" instead of "signature", as suggested in  
Section 9.   HMAC is a (symmetric) message authentication code, and  
not an (asymmetric) digital signature algorithm.  See RFC 4949 for  
instance for the appropriate definitions.  Calling HMAC a signature  
method will confuse readers going forward and potentially set  
incorrect expectations. I suggest the following changes (not because I  
think these are the only good alternatives, but because I want to be  
constructive):

"JSON Web Signature" -> "JSON Web Authentication"
"sign" -> "authenticate"
"signing" -> "authenticating"
"signature" -> "authentication data"

The security considerations of json-web-signature should explain the  
difference between symmetric and asymmetric encryption.

Section 9 mentions the possibility of including an unkeyed checksum  
based on SHA-256.  If that is done, then that will potentially confuse  
the issue further.  What would the value of that checksum be, and  
would it be a security mechanism?   If it is defined, I suggest that  
it be done in a different draft.

Why are we allowing unauthenticated encryption in draft-jones-json-web- 
encryption?   Authenticated Encryption with Associated Data (AEAD) is  
recommended (in the form of AES-GCM) in the draft, and it avoids all  
sorts of security issues that are present with unauthenticated  
encryption (besides being theoretically vulnerable, it has fallen  
victim to practical attacks [1][2][3][4][5][6][7][8]).  Note that some  
of these attacks apply when encryption is loosely bound to  
authentication.  I suggest that AEAD be the only encryption method,  
and that an RFC 5116 interface be included.  Since GCM is recommended,  
the interface is already there, but not called out.  Omitting  
unauthenticated encryption will simplify the spec, and improve  
security.  If there is some percieved issue with AES-GCM, there are  
other AEAD algorithms that can be used, AES-SIV (synthetic IV mode)  
for instance, or a generic CBC+HMAC composition.   In any case, I  
offer to help craft and/or review this text.

A minor point: JWE recommends AES-GCM; why not have json-web-signature  
recommend AES-GMAC?

json-web-signature says that "Related encryption capabilities are  
described in the separate JSON Web Encryption (JWE) specification".   
The JWE specification says that "In general, senders SHOULD sign the  
message and then encrypt the result (thus encrypting the  
signature)".   There ought to be better recommendations for security.   
For instance, encryption without authentication should be disallowed.

regards,

David

--

[1] Vaudenay, "Security Flaws Induced by CBC Padding Applications to  
SSL, IPSEC, WTLS...", EUROCRYPT 2002.

[2] Rizzo, Duong, "Practical Padding Oracle Attacks", Black Hat  
Europe, 2010.

[3] Jager, Somorovsky, "How To Break XML Encryption", 18th ACM  
Conference on Computer and Communications Security (CCS), 2011.

[4] Bellare, Kohno, Namprempre, "Breaking and provably repairing the  
SSH authenticated encryption scheme: A case study of the Encode-then- 
Encrypt-and-MAC paradigm", ACM Transactions on Information and System  
Security, May 2004.

[5] Rizzo, Thai, "BEAST: Surprising crypto attack against HTTPS",  
Ekoparty, 2011.

[6] Bellovin, “Problem Areas for the IP Security Protocols”, Sixth  
Usenix Unix Security Symposium, 1996.

[7] Paterson, Yau, “Cryptography in theory and practice: The case of  
encryption in IPsec”, EUROCRYPT 2006,

[8] Degabriele, Paterson, "Attacking the IPsec Standards in Encryption- 
only Conﬁgurations", IEEE Symposium on Security and Privacy, 2007.

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 16 Nov 2011 01:50:16 +0000

At the same time we don't want to confuse folks the other way to have them think we are not addressing signature. The WG name does have signing in it. One option would be to split out the MAC from the signing

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David McGrew
Sent: Tuesday, November 15, 2011 4:40 AM
To: [email-masked]
Subject: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption

Hi

I would like to contribute the following comments.  I have not been closely following the WG, so apologies in advance if I'm rehashing something.

The json-web-signature draft should be changed by using the more generic "authentication" instead of "signature", as suggested in  
Section 9.   HMAC is a (symmetric) message authentication code, and  
not an (asymmetric) digital signature algorithm.  See RFC 4949 for instance for the appropriate definitions.  Calling HMAC a signature method will confuse readers going forward and potentially set incorrect expectations. I suggest the following changes (not because I think these are the only good alternatives, but because I want to be
constructive):

The security considerations of json-web-signature should explain the difference between symmetric and asymmetric encryption.

Section 9 mentions the possibility of including an unkeyed checksum based on SHA-256.  If that is done, then that will potentially confuse the issue further.  What would the value of that checksum be, and  
would it be a security mechanism?   If it is defined, I suggest that  
it be done in a different draft.

recommended (in the form of AES-GCM) in the draft, and it avoids all sorts of security issues that are present with unauthenticated encryption (besides being theoretically vulnerable, it has fallen victim to practical attacks [1][2][3][4][5][6][7][8]).  Note that some of these attacks apply when encryption is loosely bound to authentication.  I suggest that AEAD be the only encryption method, and that an RFC 5116 interface be included.  Since GCM is recommended, the interface is already there, but not called out.  Omitting unauthenticated encryption will simplify the spec, and improve security.  If there is some percieved issue with AES-GCM, there are other AEAD algorithms that can be used, AES-SIV (synthetic IV mode)  

A minor point: JWE recommends AES-GCM; why not have json-web-signature recommend AES-GMAC?

The JWE specification says that "In general, senders SHOULD sign the message and then encrypt the result (thus encrypting the  

regards,

David

--

[1] Vaudenay, "Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002.

[2] Rizzo, Duong, "Practical Padding Oracle Attacks", Black Hat Europe, 2010.

[3] Jager, Somorovsky, "How To Break XML Encryption", 18th ACM Conference on Computer and Communications Security (CCS), 2011.

[4] Bellare, Kohno, Namprempre, "Breaking and provably repairing the SSH authenticated encryption scheme: A case study of the Encode-then- Encrypt-and-MAC paradigm", ACM Transactions on Information and System Security, May 2004.

[5] Rizzo, Thai, "BEAST: Surprising crypto attack against HTTPS", Ekoparty, 2011.

[6] Bellovin, “Problem Areas for the IP Security Protocols”, Sixth Usenix Unix Security Symposium, 1996.

[7] Paterson, Yau, “Cryptography in theory and practice: The case of encryption in IPsec”, EUROCRYPT 2006,

[8] Degabriele, Paterson, "Attacking the IPsec Standards in Encryption- only Conﬁgurations", IEEE Symposium on Security and Privacy, 2007.

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

---

From: Mike Jones <[email-masked]>
Date: Wed, 16 Nov 2011 01:57:37 +0000

Upon reflection since Monday's meeting, I believe that the draft title should stay "JSON Web Signature" (as Tony pointed out, "Signing" is in the WG's name!) but the text should be clear that the spec describes both how to perform digital signatures and how to perform HMAC operations).  It will no longer use the term "signing" when referring to HMAC operations.

As Eric Rescorla pointed out during the meeting, the problem with splitting out HMAC into a different spec is that the preparation of the content is essentially identical between the two kinds of operations.  The amount of duplication resulting wouldn't be doing the users of the specs any favors.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David McGrew
Sent: Tuesday, November 15, 2011 4:40 AM
To: [email-masked]
Subject: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption

Hi

regards,

David

--

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 16 Nov 2011 12:14:34 +0800

+1

Also, Re:David's proposal for use of word "Authentication": I am ok with
"Message Authentication" but against just using stand alone
"Authentication". It is a way too overloaded word and causes unnecessary
confusion.

On Wed, Nov 16, 2011 at 9:57 AM, Mike Jones <[email-masked]>wrote:

> Upon reflection since Monday's meeting, I believe that the draft title
> should stay "JSON Web Signature" (as Tony pointed out, "Signing" is in the
> WG's name!) but the text should be clear that the spec describes both how
> to perform digital signatures and how to perform HMAC operations).  It will
> no longer use the term "signing" when referring to HMAC operations.
>
> As Eric Rescorla pointed out during the meeting, the problem with
> splitting out HMAC into a different spec is that the preparation of the
> content is essentially identical between the two kinds of operations.  The
> amount of duplication resulting wouldn't be doing the users of the specs
> any favors.
>
>                                -- Mike
>
> At the same time we don't want to confuse folks the other way to have them
> think we are not addressing signature. The WG name does have signing in it.
> One option would be to split out the MAC from the signing
>
> The json-web-signature draft should be changed by using the more generic
> "authentication" instead of "signature", as suggested in
> instance for the appropriate definitions.  Calling HMAC a signature method
> will confuse readers going forward and potentially set incorrect
> expectations. I suggest the following changes (not because I think these
> are the only good alternatives, but because I want to be
> constructive):
>
> Section 9 mentions the possibility of including an unkeyed checksum based
> on SHA-256.  If that is done, then that will potentially confuse the issue
> further.  What would the value of that checksum be, and
> recommended (in the form of AES-GCM) in the draft, and it avoids all sorts
> of security issues that are present with unauthenticated encryption
> (besides being theoretically vulnerable, it has fallen victim to practical
> attacks [1][2][3][4][5][6][7][8]).  Note that some of these attacks apply
> when encryption is loosely bound to authentication.  I suggest that AEAD be
> the only encryption method, and that an RFC 5116 interface be included.
>  Since GCM is recommended, the interface is already there, but not called
> out.  Omitting unauthenticated encryption will simplify the spec, and
> improve security.  If there is some percieved issue with AES-GCM, there are
> [3] Jager, Somorovsky, "How To Break XML Encryption", 18th ACM Conference
> on Computer and Communications Security (CCS), 2011.
>
> [4] Bellare, Kohno, Namprempre, "Breaking and provably repairing the SSH
> authenticated encryption scheme: A case study of the Encode-then-

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: David McGrew <[email-masked]>
Date: Wed, 16 Nov 2011 04:25:46 -0800

Hi Mike,

On Nov 15, 2011, at 5:57 PM, Mike Jones wrote:

> Upon reflection since Monday's meeting, I believe that the draft  
> title should stay "JSON Web Signature" (as Tony pointed out,  
> "Signing" is in the WG's name!)

we should not be concerned about consistency with the WG name, but  
instead about the perceptions of the reader.  We can't blame the  
reader for expecting an RFC with "signatures" in its name to provide  
asymmetric authentication.  Will implementations that include the  
symmetric message authentication code, but lack any actual signature  
mechanisms, be able to claim conformance to the specification?

> but the text should be clear that the spec describes both how to  
> perform digital signatures and how to perform HMAC operations).  It  
> will no longer use the term "signing" when referring to HMAC  
> operations.
>

Great, that's a key point.

> splitting out HMAC into a different spec is that the preparation of  
> the content is essentially identical between the two kinds of  
> operations.  The amount of duplication resulting wouldn't be doing  
> the users of the specs any favors.

Avoiding duplication is a good goal.  Another way to achieve it, while  
being more clear about what conformance to the spec means, is to have  
two drafts, with the MAC draft using definitions from the Signature  
draft.  Say, the Signature draft could have a section or two that  
applies to both, and the MAC draft references those sections.

If there is only going to be one draft, then I strongly encourage the  
WG to use a generic term like "authentication" in the title, or to  
have the title describe both security mechanisms: "JSON Web Signature  
and Message Authentication".

David

> At the same time we don't want to confuse folks the other way to  
> have them think we are not addressing signature. The WG name does  
> have signing in it. One option would be to split out the MAC from  
> the signing
>
> incorrect expectations. I suggest the following changes (not because  
> I think these are the only good alternatives, but because I want to be
> constructive):
>
> based on SHA-256.  If that is done, then that will potentially  
> confuse the issue further.  What would the value of that checksum  
> be, and
> victim to practical attacks [1][2][3][4][5][6][7][8]).  Note that  
> some of these attacks apply when encryption is loosely bound to  
> and that an RFC 5116 interface be included.  Since GCM is  
> recommended, the interface is already there, but not called out.   
> Omitting unauthenticated encryption will simplify the spec, and  
> improve security.  If there is some percieved issue with AES-GCM,  
> there are other AEAD algorithms that can be used, AES-SIV (synthetic  
> IV mode)
> SSH authenticated encryption scheme: A case study of the Encode- 
> then- Encrypt-and-MAC paradigm", ACM Transactions on Information and  
> System Security, May 2004.
>
> [6] Bellovin, “Problem Areas for the IP Security Protocols”,  
> Sixth Usenix Unix Security Symposium, 1996.
>
> [8] Degabriele, Paterson, "Attacking the IPsec Standards in  
> Encryption- only Conﬁgurations", IEEE Symposium on Security and  
> Privacy, 2007.
>
>
>
>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 16 Nov 2011 22:50:22 +0800

"JSON Web Signature and Message Authentication" is a bit verbose, but
accurate so I like it.

=nat

On Wed, Nov 16, 2011 at 8:25 PM, David McGrew <[email-masked]> wrote:

>> WG's name!)
> we should not be concerned about consistency with the WG name, but instead
> about the perceptions of the reader.  We can't blame the reader for
> expecting an RFC with "signatures" in its name to provide asymmetric
> authentication.  Will implementations that include the symmetric message
> authentication code, but lack any actual signature mechanisms, be able to
> claim conformance to the specification?
>
>
>  but the text should be clear that the spec describes both how to perform
>> digital signatures and how to perform HMAC operations).  It will no longer
>> use the term "signing" when referring to HMAC operations.
>>
>>
> being more clear about what conformance to the spec means, is to have two
> drafts, with the MAC draft using definitions from the Signature draft.
>  Say, the Signature draft could have a section or two that applies to both,
> and the MAC draft references those sections.
>
> If there is only going to be one draft, then I strongly encourage the WG
> to use a generic term like "authentication" in the title, or to have the
> title describe both security mechanisms: "JSON Web Signature and Message
> Authentication".
>
> David
>
>
>
>>                                -- Mike
>>
>> Subject: Re: [jose] comments on draft-jones-json-web-signature and
>> draft-jones-json-web-**encryption
>>
>> At the same time we don't want to confuse folks the other way to have
>> them think we are not addressing signature. The WG name does have signing
>> in it. One option would be to split out the MAC from the signing
>>
>> Subject: [jose] comments on draft-jones-json-web-signature and
>> draft-jones-json-web-**encryption
>>
>> Hi
>>
>> sorts of security issues that are present with unauthenticated encryption
>> ______________________________**_________________
>> jose mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/jose<https://www.ietf.org/mailman/listinfo/jose>
>> ______________________________**_________________
>> jose mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/jose<https://www.ietf.org/mailman/listinfo/jose>
>>
>
> ______________________________**_________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/jose<https://www.ietf.org/mailman/listinfo/jose>
>

---

From: John Bradley <[email-masked]>
Date: Wed, 16 Nov 2011 17:46:33 -0300

+1
On 2011-11-16, at 11:50 AM, Nat Sakimura wrote:

> "JSON Web Signature and Message Authentication" is a bit verbose, but accurate so I like it. 
> 
> =nat
> 
> Upon reflection since Monday's meeting, I believe that the draft title should stay "JSON Web Signature" (as Tony pointed out, "Signing" is in the WG's name!)
> 
> we should not be concerned about consistency with the WG name, but instead about the perceptions of the reader.  We can't blame the reader for expecting an RFC with "signatures" in its name to provide asymmetric authentication.  Will implementations that include the symmetric message authentication code, but lack any actual signature mechanisms, be able to claim conformance to the specification?
> 
> 
> but the text should be clear that the spec describes both how to perform digital signatures and how to perform HMAC operations).  It will no longer use the term "signing" when referring to HMAC operations.
> 
> 
> Avoiding duplication is a good goal.  Another way to achieve it, while being more clear about what conformance to the spec means, is to have two drafts, with the MAC draft using definitions from the Signature draft.  Say, the Signature draft could have a section or two that applies to both, and the MAC draft references those sections.
> 
> If there is only going to be one draft, then I strongly encourage the WG to use a generic term like "authentication" in the title, or to have the title describe both security mechanisms: "JSON Web Signature and Message Authentication".
> 
> David
> 
> 
> 
>                                -- Mike
>

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Wed, 16 Nov 2011 20:53:05 +0000

+1

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Nov 2011 15:59:32 -0500

As a legal matter, the US has legislation that recognizes someone saying
'Yes' into a telephone handset as an 'Electronic Signature'.

MACs are not digital signatures but they are clearly an acceptable
electronic signature under that act. So I don't see that there is really a
problem including MACs in a 'signature document' provided that users
understand this.

The term 'signature' has several meanings in and out of the field. A legal
signature has five or six different significances and digital signatures
only provide equivalents for some of them.

I would rather just keep the term as it is rather than rathole on it. The
terms Authentication and Integrity are not synonymous either, as some
people seem to be suggesting. Trying to make this wording more accurate
seems to be having the opposite effect to me.

A MAC and a Digital Signature always provide an integrity check but they
only provide a proof of authenticity if the provenance of the verification
key is established.

If I buy a Ming Vase, the integrity of the vase is demonstrated by checking
that it is not chipped, the authenticity of the vase depends on it actually
being Ming Dynasty.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 17 Nov 2011 08:54:55 +0800

Mike,

I think that while the structures for JWS might need to undergo some changes that will mean that while the MAC and Digital Signature structures.  As I mentioned at the F2F meeting, I know of someone is doing some small device work where they are sending messages from the devices to more central locations.  In this case there is not a pre-existing shared secret generally between the two entities and they are not using TLS so they could not derive one from the session key.  Mapping what they do into the current JWS work would require some changes. Specifically

Header Object
   - contains a MAC algorithm to be used - generally AES-GMAC
   - contains a key wrapping algorithm - generally AES key wrap
   - contains a key agreement algorithm - generally EC-DH
Key Exchange Value - the CEK wrapped by the KEK where the KEK came from the static-static EC-DH algorithm
Body
MAC value

In this case we have four not three items that need to be placed in the sequence of items to be sent between the originator and the verifier.  I would still compute the MAC value in much the same way, only I would compute the MAC over the first three elements instead of the two elements.

This is the sort of thing that is used in a more store and forward environment or one where the answer is going to be pre-computed or where it needs to last longer than just the current session (i.e. later validation).

The same type of thing can be used for a long term shared KEK value on both the sender and recipient, where a unique CEK is generated for each message and wrapped.  David would be a better person than I am to address the question of security.  -"Do you have more security by doing an indirection and have a fresh key for doing the MAC on each operation rather than using the long term key for doing the MAC."  

If we did the above change, then I would say that the "Key Exchange Value" would become and empty string if you have a key derivied from the TLS session that you are using - but this would still lead to having four not three elements in the MAC case.

Jim

---

From: Leif Johansson <[email-masked]>
Date: Thu, 17 Nov 2011 02:55:01 +0100

> "JSON Web Signature" -> "JSON Web Authentication" "sign" ->
> "authenticate" "signing" -> "authenticating" "signature" ->
> "authentication data"

I don't think this is quite right. Signature != public key signature
so I don't think the terminology issue is that serous. However saying
authentication carries other connotations that would be confusing.

I suggest leave the terms as they are.

	Cheers Leif