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

[Mike Jones <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Anthony Nadalin
Sent: Tuesday, November 15, 2011 5:50 PM
To: David McGrew; [e-mail]
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

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of David McGrew
Sent: Tuesday, November 15, 2011 4:40 AM
To: [e-mail]
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):

"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.




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