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 Configurations", IEEE Symposium on Security and Privacy, 2007.