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

["Jeremy Laurenson (jlaurens)" <[e-mail]>]

+1

On Nov 16, 2011, at 9:50 AM, Nat Sakimura wrote:

> "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 <[e-mail]> wrote:
> 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.
> 
> 
> 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.
> 
> 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
> 
> -----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
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose